Java Memory Model
summary
Describes why the original Java memory model is broken and how JSR-133 replaces it with concrete guarantees: strengthened final semantics, well-defined volatile behavior implemented as a store fence after write and load fence before read, and synchronized semantics that force cache flushes. Shows how hardware (registers, L1/L3 caches, MESI protocol) and JVM optimizations caused divergent implementations, explains that JVMs were unified by the new model, and reports measured performance costs as negligible. Slides: http://goo.gl/KFEjWe
AI-written summary · about
chapters (8)
- 0:00Introduction to speakers
- 1:37What is memory consistency
- 4:49Hardware memory models
- 9:32Java Memory Model basics
- 13:07Old Java model flaws
- 15:47Volatile and final explained
- 18:04Why built-in model wins
- 20:08Model clash and performance
related talks
41mJava Memory Consistency Model
40mA practical approach to Java Memory Model
45mJava Memory Consistency Model
49mUnconventional memory model extensions in practice
58mClose Encounters of the JMM Kind
36mConcurrency — Java Memory Model — Not Just for Eagles
01h 11mProgramming language memory models: Problems, solutions, and directions
48mNot Just Happens-Before: Unconventional Semantics
