The Azul Hardware Transactional Memory experience

Back in 2006-2010 Azul made custom hardware for running Big Business Java — basically a super-computer for running e.g. web portals written in Java. The hardware had many innovations, and most were geared towards Java's special needs (read barriers for low-latency GC, support range-checked array operations, virtual calls). Probably the most innovative hardware was the Hardware Transactional Memory — the entire L1 of every one of the 864 cores could do a transactional update! This was specifically designed to allow transactional update of Java locks — to allow concurrent execution of Java synchronized blocks as long as there was no actual memory update conflict.

The HTM was really strong — transactions could be as large as the entire L1 cache — yet in practice it was not good enough to run Java synchronized blocks concurrently. Cliff will tell you why it didn't work and why HTM/STM in general will not allow concurrent execution in practice.