Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Java Memory Consistency Model - context and concepts

Java Memory Consistency Model - context and concepts

Several concepts and characters whose work gives better context to understand what is JMCM and what is it for, including:

- Gordon Moore
- Gene Amdahl
- Leslie Lamport
- Bill Pugh
- Sarita Adve
- Martin Thompson

Also covers usual fallacies about JMCM, related Java keywords, JMCM definitions and best advice ever given (by none other than Doug Lea).

Presented at 4Developers 2015.

Tomasz Borek

April 20, 2015
Tweet

More Decks by Tomasz Borek

Other Decks in Programming

Transcript

  1. Today... • A little bragging • Fallacy correction • Memory

    model • The Java one mostly • Short advice what about it • Lot of links for later reading • Yeah, 45 minutes only :P @LAFK_pl Consultant @
  2. Who knows (heard of)? • Gene Amdahl? • Gordon Moore?

    • Leslie Lamporte? • Bill Pugh? • Sarita Adve? • Hans Boehm? • Martin Thompson? • Aleksey Shipilev? @LAFK_pl
  3. Hands up, who... • Doesn't program • Knows Moore's law?

    • Knows Amdahl's law? • Can explain concurrency vs parallelism? • Codes with mechanical sympathy? • Tries to? • Knows what mechanical sympathy is? @LAFK_pl
  4. Not true at all! @LAFK_pl Java Memory Model is about

    GC, memory management, Eden, Survivors, etc.
  5. JLS, section 17.4: A memory model describes, given a program

    and an execution trace of that program, whether the execution trace is a legal execution of the program. The Java programming language memory model works by examining each read in an execution trace and checking that the write observed by that read is valid according to certain rules. @LAFK_pl Consultant @
  6. JLS, section 17.4: A memory model describes, given a program

    and an execution trace of that program, whether the execution trace is a legal execution of the program. The Java programming language memory model works by examining each read in an execution trace and checking that the write observed by that read is valid according to certain rules. @LAFK_pl Consultant @
  7. Aleksey Shipilev: @LAFK_pl Consultant @ Memory model answers one simple

    question: What values can a particular read in a program return?
  8. Bill Pugh, Jeremy Manson • Most cores have many cache

    layers • What if 2 cores look at same value? • Memory model defines when and who sees what • There're strong and weak models • Strong guarantee seeing same things across whole system • Weak only sometimes, via barriers / fences @LAFK_pl Consultant @
  9. Bill Pugh, Jeremy Manson: What is a memory model, anyway?

    At the processor level, a memory model defines necessary and sufficient conditions for knowing that writes to memory by other processors are visible to the current processor, and writes by the current processor are visible to other processors. @LAFK_pl Consultant @
  10. So? • Memory CONSISTENCY • Allowed optimisations • Possible executions

    of a (possibly multithreaded!) program • Which cores / threads see which values • How to make it consistent for programmers • What you're allowed to assume @LAFK_pl Consultant @
  11. Fallacy #1 I don't need to worry about JMCM since

    REALLY smart engineers crafted it. @LAFK_pl Consultant @
  12. Half-true I don't need to worry about JMCM since REALLY

    smart engineers crafted it @LAFK_pl Consultant @
  13. Smart, sure! But still: • Smart people are still people

    • JMCM is damn hard! Yeah, they botched it. • Java <> JVM • JMCM is for JVM... but with Java in mind • NO tech is a talisman of functionality! @LAFK_pl Consultant @
  14. JSR-133? • Messed up final • Spec not for humans

    • Messed up double-locking • Messed up volatile • Each implementation on it's own @LAFK_pl Consultant @
  15. Depends! • What you write and with what • Java?

    Not? • Need performance? • What platforms? • Multicore era... @LAFK_pl Consultant @
  16. Moore's ”law” I see Moore’s law dying here in the

    next decade or so. – Gordon Moore, 2015 Consultant @ @LAFK_pl Consultant @
  17. Amdahl's law @LAFK_pl The speedup of a program using multiple

    processors in parallel computing is limited by the sequential fraction of the program. For example, if 95% of the program can be parallelized, the theoretical maximum speedup using parallel computing would be 20× as shown in the diagram, no matter how many processors are used. Consultant @
  18. Rok 1967, Gene Amdahl states: @LAFK_pl For over a decade

    prophets have voiced the contention that the organization of a single computer has reached its limits and that truly significant advances can be made only by interconnection of a multiplicity of computers in such a manner as to permit cooperative solution. Consultant @
  19. Rok 1967, Gene Amdahl states: @LAFK_pl For over a decade

    prophets have voiced the contention that the organization of a single computer has reached its limits and that truly significant advances can be made only by interconnection of a multiplicity of computers in such a manner as to permit cooperative solution. Consultant @
  20. Where it matters • Javac / Jython / ... •

    JIT • Hardware, duh! • Each time: another team @LAFK_pl Consultant @
  21. Hardware • Various ISA CPUs • Number of registers •

    Caches size or type, buses implementations • Cache protocols (MESI, AMD's MOESI, Intel's...) • How many functional units per CPU • How many CPUs • Pipeline: • Instruction decode > address decode > memory fetch > register fetch > compute ... @LAFK_pl Consultant @
  22. Program / code optimizations? • Reorder • (e.g. prescient store)

    • Remove what's unnecessary • (e.g. synchronize) • Replace instructions / shorten machine code • Function optimizations • (e.g. Inlining) • ... @LAFK_pl Consultant @
  23. Barriers / fences „once memory has been pushed to the

    cache then a protocol of messages will occur to ensure all caches are coherent for any shared data. The techniques for making memory visible from a processor core are known as memory barriers or fences. – Martin Thompson, Mechanical Sympathy differs per architecture / CPU / cache type! @LAFK_pl Consultant @
  24. Barriers / Fences • CPU instruction • Means ”flush BUFFER

    now!” • CMPXCHG (may be lacking!) • Forces update • Starts cache coherency protocols • Read / Write / Full @LAFK_pl Consultant @
  25. Doug Lea says: @LAFK_pl Consultant @ The best way is

    to build up a small repertoire of constructions that you know the answers for and then never think about the JMM rules again unless you are forced to do so! Literally nobody likes figuring things out of JMM rules as stated, or can even routinely do so correctly. This is one of the many reasons we need to overhaul JMM someday.
  26. Doug Lea advice: @LAFK_pl Consultant @ The best way is

    to build up a small repertoire of constructions that you know the answers for and then never think about the JMM rules again unless you are forced to do so! Literally nobody likes figuring things out of JMM rules as stated, or can even routinely do so correctly. This is one of the many reasons we need to overhaul JMM someday.
  27. Mechanical sympathy: @LAFK_pl Consultant @ • Cache lines misses hurt

    • Going to main memory hurts • Cycles are important • L1, L2 caches are cheap but require cache coherency protocols and memory barriers • Not every hardware has all barriers •
  28. Bill Pugh • FindBugs • Java Memory Model is broken

    • Final - Volatile • Double-checked locking • ”New” JMM @LAFK_pl
  29. Sarita Adve • Java Memory Model is broken • Great

    many MCM papers • Best MCM def I found @LAFK_pl
  30. Martin Thompson • Mechanical sympathy blog & mailing list •

    Aeron protocol • Mechanical sympathy proponent @LAFK_pl
  31. This wouldn't have happened if not • Jarek Pałka, who

    kicked me out here some time ago • Those folks, who said ”make more” after the lightning talk I've done • Java Day Kiev 2014 @LAFK_pl Consultant @
  32. Not possible without: • Leslie Lamport's works on distributed sistems

    • Bill Pugh's work on JSR-133! http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html • Sarita Adve's paperts, especially shared MCM tutorial: http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-95-7.pdf @LAFK_pl Consultant @
  33. Terrific – and tough - reading • Martin Thompson: Mechanical

    Sympathy (mailing list & blog ) • JEPS 188: http://openjdk.java.net/jeps/188 • Goetz et al: "Java Concurrency in Practice" • Herilhy, Shavit, "The Art of Multiprocessor Programming" • Adve, "Shared Memory Consistency Models: A Tutorial" • Manson, "Special PoPL Issue: The Java Memory Model" • Huisman, Petri, "JMM: A Formal Explanation" • Aleksey Shipilev blog post: http://shipilev.net/blog/2014/jmm-pragmatics/ @LAFK_pl Consultant @
  34. Laws and related: • Moore's ”law”: http://www.cs.utexas.edu/~fussell/courses/cs352h/papers/moore.pdf • Rock's law:

    http://en.wikipedia.org/wiki/Rock's_law • Amdahl's law: • http://en.wikipedia.org/wiki/Amdahl%27s_law • Validity of the Single-Processor Approach to Achieving Large-Scale Computing Capabilities AFIPS Press, 1967 • J.L. Gustafson, “Reevaluating Amdahl’s Law,” Comm. ACM, May 1988 • Pleasantly parallel problems: http://en.wikipedia.org/wiki/Embarrassingly_parallel @LAFK_pl Consultant @
  35. Special thanks • Konrad Malawski and Tomek Kowalczewski, these guys

    really dig that stuff • Bartosz Milewski who helped me rediscover Hans Boehm @LAFK_pl Consultant @