Java Memory Model and Happens-Before Internals

Recently I jumped into some concurrency code that takes advantage of happens-before guarantee to ensure a specific configuration was loaded in an executing thread. I was also aware that a good bunch of java concurrency classes, especially AbstractQueuedSynchronizer, makes usage of same synchronization piggybacking technique.

Although Java Memory Model is documented well, I was still wondering which assembler instructions are used to ensure “happens-before” guarantees at multi-core CPU level.
I managed to get some free time and play with java at low level and tested three synchronization techniques. I also found a good documentation explaining  Synchronized Memory Access details.
According to Microsoft’s x86 Architecture following actions happen for lock instructions.

1. Before issuing the instruction, the CPU will flush all pending memory operations to ensure coherency. All data pre-fetches are abandoned.
   
2. While issuing the instruction, the CPU will have exclusive access to the bus. This ensures the atomicity of the load/modify/store operation.

Below, I will detail how java concurrency utilities are translated to low level assembler instructions. Details of assembly printing can be found on PrintAssembly wiki page.

Synchronized

That technique uses synchronized keyword to lock variables properly. As it synchs whole method block, therefore there are two lock cmpxchg instructions in the generated assembly code.

Volatile

Below code piece uses volatile keyword to set the counter value.

Volatile keyword causes inserting a lock instruction to ensure happens-before guarantees and flushes pending changes to make sure these changes are visible.

Atomic

Below code shows a simple AtomicInteger being used a counter.

When above code is executed with -XX:+UnlockDiagnosticVMOptions   -XX:CompileCommand=print,Counter.inc, similar assembly instructions are seen in the assembly dump log.