6.1 Hardware Foundations for Concurrency

1. Memory Hierarchy

CPUs are much faster than main memory, so modern machines use registers and multiple cache levels to exploit temporal and spatial locality.

This hierarchy improves performance but means one source-level load/store is not equivalent to “immediately read/write DRAM.”

2. Cache Coherence

Multiple cores may cache the same physical cache line. Coherence protocols such as MESI-family protocols keep writes to a single location coherent across cores.

Coherence is not the same as a memory-ordering model. A machine can keep one address coherent while still allowing loads/stores to different addresses to become observable in orders different from source code.

3. Reordering

Compilers and CPUs may reorder independent operations as long as they preserve the guarantees of their respective models.

Modern CPUs also use pipelines, speculation, store buffers, and out-of-order execution. These are performance mechanisms, not evidence that programs execute literally in source order.

4. Memory Barriers

Architectures provide fences/barriers that constrain allowed ordering of memory operations.

A barrier should be understood by its architectural ordering guarantee, not as a universal command to “flush CPU caches to main memory.” x86-64 and ARM have different memory-ordering strengths and instruction sets.

5. Why Java Needs the JMM

Java runs across different processors and JVM implementations. The Java Memory Model defines source-level concurrency semantics—visibility, ordering, synchronization, and legal executions—so Java code does not depend directly on one CPU’s cache protocol.

The JVM/JIT maps Java synchronization operations onto whatever compiler barriers, atomic instructions, and hardware fences are required for the target platform.