4developers 2015: java memory consistency model or intro to multithreaded programming - tomasz...

Java Memory Consistency Model

@LAFK_plConsultant @

Tomasz Borek

GeeCON 2015 Kraków!


http://2015.geecon.org/register/



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


Symentis

@LAFK_pl

Symentis

@LAFK_pl

Jarosław Pałka Kuba Marchwicki

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


Who knows (heard of)?

● Gene Amdahl?● Gordon Moore?● Leslie Lamporte?● Bill Pugh?● Sarita Adve?● Hans Boehm?● Martin Thompson?● Aleksey Shipilev?

@LAFK_pl

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

Fallacy #0

@LAFK_pl

Java Memory Model is about GC, memory management, Eden, Survivors etc.

Not true at all!

@LAFK_pl

Java Memory Model is about GC, memory management, Eden, Survivors, etc.

@LAFK_pl

MANAGEMENT!!

@LAFK_pl

Written in 2012...

@LAFK_pl

… and still there

@LAFK_pl

Correction!


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.


Sarita Adve: memory consistency model


Aleksey Shipilev:


Memory model answers one simple question:What values can a particular read in a program

return?

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


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.


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


Fallacy #1

I don't need to worry about JMCM since REALLY smart engineers crafted it.


Half-true

I don't need to worry about JMCM since REALLY smart engineers crafted it


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!


JSR-133?

● Messed up final● Spec not for humans● Messed up double-locking● Messed up volatile● Each implementation on it's own


More?


JEPS-188 and JMM9?

Fallacy #2

JMCM is irrelevant for me.


Depends!

● What you write and with what● Java? Not?● Need performance?● What platforms?

● Multicore era...


Fallacy #3

JMCM is for fanatics. I have frameworks for that.


Moore's ”law”?

Consultant @ Consultant @ @LAFK_pl

Moore's ”law”

I see Moore’s law dying here in the next decade or so.

– Gordon Moore, 2015

Consultant @ @LAFK_pl

Consultant @

Amdahl's law?

@LAFK_pl Consultant @

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 @

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 @

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 @

Cores... MOAR!!

@LAFK_pl Consultant @

Data distance

● http://i.imgur.com/k0t1e.png

So, data distance varies

@LAFK_pl

Know thyne cache lines!

Consultant @


So if it matters, what then?

Where it matters

● Javac / Jython / ...● JIT

● Hardware, duh!

● Each time: another team


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


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)

● ...


Exemplary CPU


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!


Barriers / Fences● CPU instruction● Means ”flush BUFFER now!”● CMPXCHG (may be

lacking!)

● Forces update● Starts cache coherency

protocols

● Read / Write / Full



Words of summary and gratitude

Doug Lea says:


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.

Doug Lea advice:


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.

Mechanical sympathy:


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

Gordon Moore

● Fairchild Semi-conductors co-founder

● ”Law author”

● Intel co-founder

@LAFK_pl

Gene Amdahl

● IBM fellow

● IBM & Amdahl mainframes

● Coined law in 1967

@LAFK_pl

Leslie Lamport

● Distributed system clocks

● Happens before

● Sequential consistency

@LAFK_pl

Bill Pugh

● FindBugs

● Java Memory Model is broken● Final - Volatile● Double-checked

locking

● ”New” JMM

@LAFK_pl

Sarita Adve

● Java Memory Model is broken

● Great many MCM papers

● Best MCM def I found

@LAFK_pl

Martin Thompson

● Mechanical sympathy blog & mailing list

● Aeron protocol

● Mechanical sympathy proponent

@LAFK_pl

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


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


http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html

http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-95-7.pdf

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/


http://openjdk.java.net/jeps/188

http://shipilev.net/blog/2014/jmm-pragmatics/

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


http://en.wikipedia.org/wiki/Rock's_law

http://en.wikipedia.org/wiki/Amdahl%27s_law

http://en.wikipedia.org/wiki/Embarrassingly_parallel

Special thanks

● Konrad Malawski and Tomek Kowalczewski, these guys really dig that stuff

● Bartosz Milewski who helped me rediscover Hans Boehm


YOU! You persevered through!


4developers 2015: java memory consistency model or intro to multithreaded programming - tomasz...

Software