Java Memory Consistency Model
summary
Defines JMM as visibility rules not GC and shows concrete consequences: reads can legally see surprising values unless ordering or barriers force visibility. Uses JS R 133 history to justify changes to volatile and final, demonstrates timings (L1 ≈0.5 ns, branch miss ≈5 ns, L2 ≈7 ns, main memory ≈100 ns) to explain cache effects, describes memory barriers that flush store/load buffers and enforce cache coherence, and evaluates when double-checked locking is safe and when to use lock-free techniques for performance.
AI-written summary · about
chapters (7)
- 0:00Start
- 5:17Sarita Adve: memory consistency model
- 26:18Where it matters
- 29:15Program / code optimizations?
- 30:10Exemplary CPU
- 32:41Barriers / Fences
- 36:43Leslie Lamport
related talks
41mJava Memory Consistency Model
40mA practical approach to Java Memory Model
22mJava Memory Model
58mClose Encounters of the JMM Kind
36mConcurrency — Java Memory Model — Not Just for Eagles
27mThe Mutability Matrix of Pain
49mUnconventional memory model extensions in practice
48mNot Just Happens-Before: Unconventional Semantics