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.

Transcript

1. Java Memory Consistency Model
   @LAFK_pl
   Consultant @
   Tomasz Borek
   

   View Slide

2. GeeCON 2015 Kraków!
   @LAFK_pl
   Consultant @
   http://2015.geecon.org/register/
   

   View Slide

3. I'll take ALL feedback I can get.
   @LAFK_pl, #JMCM
   @LAFK_pl
   Consultant @
   

   View Slide

4. Symentis
   @LAFK_pl
   

   View Slide

5. Symentis
   @LAFK_pl
   Jarosław Pałka Kuba Marchwicki
   

   View Slide

6. 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 @
   

   View Slide

7. Who knows (heard of)?
   ●
   Gene Amdahl?
   ●
   Gordon Moore?
   ●
   Leslie Lamporte?
   ●
   Bill Pugh?
   ●
   Sarita Adve?
   ●
   Hans Boehm?
   ●
   Martin Thompson?
   ●
   Aleksey Shipilev?
   @LAFK_pl
   

   View Slide

8. 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
   

   View Slide

9. Fallacy #0
   @LAFK_pl
   Java Memory Model is about GC, memory
   management, Eden, Survivors etc.
   

   View Slide

10. Not true at all!
    @LAFK_pl
    Java Memory Model is about GC, memory
    management, Eden, Survivors, etc.
    

    View Slide

11. @LAFK_pl
    

    View Slide

12. MANAGEMENT!!
    @LAFK_pl
    

    View Slide

13. Written in 2012...
    @LAFK_pl
    

    View Slide

14. … and still there
    @LAFK_pl
    

    View Slide

15. Correction!
    @LAFK_pl
    Consultant @
    

    View Slide

16. 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 @
    

    View Slide

17. 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 @
    

    View Slide

18. Sarita Adve: memory consistency
    model
    @LAFK_pl
    Consultant @
    

    View Slide

19. Aleksey Shipilev:
    @LAFK_pl
    Consultant @
    Memory model answers one simple question:
    What values can a particular read in a program
    return?
    

    View Slide

20. 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 @
    

    View Slide

21. 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 @
    

    View Slide

22. 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 @
    

    View Slide

23. Fallacy #1
    I don't need to worry about JMCM since
    REALLY smart engineers crafted it.
    @LAFK_pl
    Consultant @
    

    View Slide

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

    View Slide

25. 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 @
    

    View Slide

26. 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 @
    

    View Slide

27. More?
    @LAFK_pl
    Consultant @
    JEPS-188 and JMM9?
    

    View Slide

28. Fallacy #2
    JMCM is irrelevant for me.
    @LAFK_pl
    Consultant @
    

    View Slide

29. Depends!
    ●
    What you write and with what
    ●
    Java? Not?
    ●
    Need performance?
    ●
    What platforms?
    ●
    Multicore era...
    @LAFK_pl
    Consultant @
    

    View Slide

30. Fallacy #3
    JMCM is for fanatics. I have frameworks for that.
    @LAFK_pl
    Consultant @
    

    View Slide

31. Moore's ”law”?
    Consultant @
    Consultant @
    @LAFK_pl
    

    View Slide

32. Moore's ”law”
    I see Moore’s law dying here in the next decade
    or so.
    – Gordon Moore, 2015
    Consultant @
    @LAFK_pl
    Consultant @
    

    View Slide

33. Amdahl's law?
    @LAFK_pl Consultant @
    

    View Slide

34. 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 @
    

    View Slide

35. 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 @
    

    View Slide

36. 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 @
    

    View Slide

37. Cores... MOAR!!
    @LAFK_pl Consultant @
    

    View Slide

38. Data distance
    ●
    http://i.imgur.com/k0t1e.png
    

    View Slide

39. So, data distance varies
    @LAFK_pl
    Know thyne cache lines!
    Consultant @
    

    View Slide

40. @LAFK_pl
    Consultant @
    So if it matters, what then?
    

    View Slide

41. Where it matters
    ●
    Javac / Jython / ...
    ●
    JIT
    ●
    Hardware, duh!
    ●
    Each time: another
    team
    @LAFK_pl
    Consultant @
    

    View Slide

42. 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 @
    

    View Slide

43. 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 @
    

    View Slide

44. Exemplary CPU
    @LAFK_pl
    Consultant @
    

    View Slide

45. 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 @
    

    View Slide

46. Barriers / Fences
    ●
    CPU instruction
    ●
    Means ”flush BUFFER now!”
    ●
    CMPXCHG (may be
    lacking!)
    ●
    Forces update
    ●
    Starts cache coherency
    protocols
    ●
    Read / Write / Full
    @LAFK_pl
    Consultant @
    

    View Slide

47. @LAFK_pl
    Consultant @
    Words of summary and gratitude
    

    View Slide

48. 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.
    

    View Slide

49. 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.
    

    View Slide

50. 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
    ●
    

    View Slide

51. Gordon Moore
    ●
    Fairchild Semi-
    conductors co-
    founder
    ●
    ”Law author”
    ●
    Intel co-founder
    @LAFK_pl
    

    View Slide

52. Gene Amdahl
    ●
    IBM fellow
    ●
    IBM & Amdahl
    mainframes
    ●
    Coined law in 1967
    @LAFK_pl
    

    View Slide

53. Leslie Lamport
    ●
    Distributed system
    clocks
    ●
    Happens before
    ●
    Sequential
    consistency
    @LAFK_pl
    

    View Slide

54. Bill Pugh
    ●
    FindBugs
    ●
    Java Memory Model
    is broken
    ●
    Final - Volatile
    ●
    Double-checked
    locking
    ●
    ”New” JMM
    @LAFK_pl
    

    View Slide

55. Sarita Adve
    ●
    Java Memory Model
    is broken
    ●
    Great many MCM
    papers
    ●
    Best MCM def I found
    @LAFK_pl
    

    View Slide

56. Martin Thompson
    ●
    Mechanical sympathy
    blog & mailing list
    ●
    Aeron protocol
    ●
    Mechanical sympathy
    proponent
    @LAFK_pl
    

    View Slide

57. 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 @
    

    View Slide

58. 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 @
    

    View Slide

59. 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 @
    

    View Slide

60. 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 @
    

    View Slide

61. Special thanks
    ●
    Konrad Malawski and Tomek Kowalczewski,
    these guys really dig that stuff
    ●
    Bartosz Milewski who helped me rediscover
    Hans Boehm
    @LAFK_pl
    Consultant @
    

    View Slide

62. YOU! You persevered through!
    @LAFK_pl
    Consultant @
    

    View Slide