GeeCON 2018: Aleksey Shipilëv - Java Memory Model Unlearning Experience
Why Stack Overflow recommends it
Stack Overflow users link it when they need a rigorous but intuitive explanation of Java Memory Model visibility, ordering and coherence, especially in questions about volatile, locks and JDK 9 memory order modes.
Recommended by 1 people across 1 different months, 2021 to 2024.
What it is
A conference talk by Aleksey Shipilëv at GeeCON 2018 that explains the Java Memory Model by showing what it is not, aiming to clear up common misconceptions about Java concurrency. It builds simple everyday rules, outlines how to prove them, and shows surprising behaviors the JMM permits. It assumes the viewer already knows basic JMM.
What people said
Strong rec Eugene · 2021-09 · Stack Overflow · on “Java synchronized block and the visibility guarantees for an explicit lock”
@markspace the ones I really cherish, are mostly in Russian (at least the good ones), here [this video] is one in English that is very good too.
Strong rec Eugene · 2021-09 · Stack Overflow · on “Java synchronized block and the visibility guarantees for an explicit lock”
@markspace the ones I really cherish, are mostly in Russian (at least the good ones), here [this video] is one in English that is very good too.
Cites 梁雨生 · 2021-01 · Stack Overflow · on “How to understand JDK9 memory model?”
I'm learning the JDK9 memory model. After watching the speech Java Memory Model Unlearning Experience [this video] and reading the paper Using JDK 9 Memory Order Modes [LINK] . I'm confused about some concepts. Does opaque immediately guarantee the visibility ? How to understand partial order and total order in the paper? For the first question, the paper says It is almost never a good idea to use bare spins waiting for values of variables. Use Thread.onSpinWait, Thread.yield, and/or blocking synchronization to better cope with the fact that "eventually" can be a long time, especially when there are more threads than cores on a system. So if I write the code: // shared variable I and VarHandle I_
Cites 梁雨生 · 2021-01 · Stack Overflow · on “Intra-thread coherence”
Maybe I should explain it, my question is derived from the `double-check` that speech [this video] shows, ``` public T get () { if (val == null) {. // point 1 synchronized (this) { if (val == null) { val = new T(); } } } return val; /// point 2 } ``` Aleksey Shipilёv says the point 1 should be coherence with point 2, I confused with this.
Cites IronWidget · 2024-09 · Stack Overflow · on “Java, volatile and memory barriers on x86 architecture”
I torched my earlier attempt to answer this because significant parts were wrong. Thanks to Peter Cordes for sending me to one resource that ballooned into a fascinating journey. Overall answer: the order of the instructions and the single lock comes from a combination of requirements imposed by the Java memory model, the memory ordering of x86, memory coherence, and optimizations. Different platforms (e.g. with ARM instead of x86) have different memory ordering and instructions and thus might need different instructions in different locations. The JSR-133 Cookbook, admittedly known for being quite conservative and also outdated, has some good discussion of the four {Store,Load}{StoreLoad} c