The document discusses the Java Memory Model (JMM). It begins by correcting common fallacies about the JMM, noting that it describes allowed program executions and thread visibility rather than garbage collection. It then provides definitions and explanations of memory models from experts like Sarita Adve and Bill Pugh. The rest of the document discusses concepts like Moore's Law, Amdahl's Law, barriers/fences, hardware impacts, and recommendations to build an understanding of JMM patterns rather than trying to fully understand the specification.

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

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

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

4. Symentis
@LAFK_pl

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

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 @

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

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

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

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

11. @LAFK_pl

12. MANAGEMENT!!
@LAFK_pl

13. Written in 2012...
@LAFK_pl

14. … and still there
@LAFK_pl

15. Correction!
@LAFK_pl
Consultant @

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 @

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 @

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

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

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 @

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 @

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 @

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

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

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 @

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 @

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

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

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

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

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

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

33. Amdahl's law?
@LAFK_pl
Consultant @

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 @

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 @

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 @

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

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

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

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

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

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 @

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 @

44. Exemplary CPU
@LAFK_pl
Consultant @

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 @

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 @

47. @LAFK_pl
Consultant @
Words of summary and gratitude

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.

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.

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
●

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

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

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

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

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

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

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 @

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 @

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 @

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 @

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 @

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