Practical Introduction to Java Memory Model

Dmitry Degrave, 2018 1
* Java Memory Model
Practical
Intro to JMM*
:
“There are only two hard things in
Computer Science: cache invalidation
and naming things” -- Phil Karlton
a journey
from Java to Asm
and Back Again
Image is the original artwork by J.R.R.Tolkien for the first edition, 1937

- OoOE
- Visibility
- volatile impl: Hotspot, C1
- volatile vs synchronized
- (Un)safe publications
- Final fields & Safe Initialization
- 4 Lazy Singleton Factories
- Atomicity
- References
Agenda
“There are only two hard things in
Computer Science: cache invalidation
and naming things” -- Phil Karlton
Image is the original artwork by J.R.R.Tolkien for the first edition, 1937

Motivation example
Thread 1 Thread 2
x = a;
b = 1;
y = b;
a = 1;
(x,y)==(0,0) ?
(x,y)==(0,1) ?
(x,y)==(1,0) ?
(x,y)==(1,1) ?
a = 0; b = 0;
(x,y) == (?,?)

Motivation example
Thread 1 Thread 2
x = a;
b = 1;
a = 1;
y = b;
Out of Order execution
a = 0; b = 0;
(x,y) == (?,?)
(x,y)==(0,0)
(x,y)==(0,1)
(x,y)==(1,0)
(x,y)==(1,1)

Runtime
(hardware & compilers)
under no obligation to
follow program order as
long as it does not modify
outcome of a program.
Single-threaded program.
details: https://en.wikipedia.org/wiki/Consistency_model
50th Anniversary Edition, J.R.R Tolkien, George Allen and Unwin, 1987
The sun is painted red as originally intended by Tolkien, but not allowed by budget for 1937 ed.

https://ourworldindata.org/wp-content/uploads/
2013/05/Transistor-Count-over-time.png
AMD
RISC Superscalar pipeline
https://en.wikipedia.org/wiki/File:
Superscalarpipeline.svg

Bytecode Machine code
reorder
Compiler/
JIT
Hardware
MM
Execution order
reorder*
*Doesn’t have to be actual OoOE, it’s memory effects that matter
strong->weak
PC/TSO/PSO/RMO/RC

x = a;
synchronized (this) {
y = b;
}
z = c;
Roach Motel

x = a;
v = b;
z = c;
x = a;
y = v;
z = c;
Volatile semantics
v - volatile

Dmitry Degrave, 2018
Visibility

Another motivation example
x == 1 ?
x == 0 ?
a = 0; b = true; x == ?
Thread 1 Thread 2
a = 1;
if (a == 1)
b = false;
while (b);
b = false;
if (!b) x = a;

What does that mean
operation is finished ?
• result of operation is in RAM
• next instruction started execution
• result is visible in point of usage
• something else

• result of operation is in RAM
• next instruction started execution
• result is visible in point of usage
• something else
What does that mean
operation is finished ?

https://en.wikipedia.org/wiki/File:Hwloc.png

Another motivation example
x == 1
x == 0
a = 0; b = true; x == ?
Thread 1 Thread 2
a = 1;
if (a == 1)
b = false;
while (b);
b = false;
if (!b) x = a;

https://docs.oracle.com/javase/specs
Original artwork by J.R.R.Tolkien for the first edition, 1937

Happens-before between threads
...
write
...
unlock
...
lock
...
read
...
...
Everything before the unlock...
...is visible to
everything after
the lock on the
same monitor in
any thread

Happens-before between threads
...
write
...
write(V)
...
read(V)
...
read
...
...
Everything before the
volatile write...
...is visible to
everything after
volatile read on
the same variable
in any thread

class A {
int a, x, y;
int b;
public void t1() {
x = a;
b = 1;
}
public void t2() {
y = b;
a = 1;
}
}
“Talk is cheap…
...show me the code” -- Linus
Image is the artwork for first Canadian paperback edition, Methuen Publications, First Printing, 1977

x = a
lir_membar_release
b = 1
lir_membar
IR*
y = b
lir_membar_acquire
a = 1
x86 / SPARC TSO
membar(StoreLoad)
-> lock / membar
no-op
no-op
* Low-Level Intermediate Representation in Hotspot
class A {
int a, x, y;
volatile int b;
public void t1() {
x = a;
b = 1;
}
public void t2() {
y = b;
a = 1;
}
}

x = a
lir_membar_release
b = 1
lir_membar
IR*
y = b
lir_membar_acquire
a = 1
PowerPC
fence -> sync ->
sync(0)
release -> lwsync()
-> sync(1)
acquire -> lwsync()
-> sync(1)
class A {
int a, x, y;
volatile int b;
public void t1() {
x = a;
b = 1;
}
public void t2() {
y = b;
a = 1;
}
}

x = a
lir_membar_release
b = 1
lir_membar
IR*
Store Memory Barrier
Store Buffers flushed
to Cache
y = b
lir_membar_acquire
a = 1
Load Memory Barrier
Invalidate Queue
Invalidated
CPU
class A {
int a, x, y;
volatile int b;
public void t1() {
x = a;
b = 1;
}
public void t2() {
y = b;
a = 1;
}
}

Happens-before between threads Recap
...
write
...
write(V)
...
read(V)
...
read
...
...
Everything before the
volatile write...
...is visible to
everything after
volatile read on
the same variable
in any thread

A journey from Java to
Asm and Back Again:
Volatile
vs
Synchronized
Image is the artwork for 75th Anniversary Edition, published by Houghton Mifflin Harcourt, 2012

public class Counter {
private volatile int counter;
public int getCounter() {
return counter;
}
public int increment() {
return counter++;
}
}
After
10 000 calls,
counter == ?

public class Counter {
private volatile int counter;
public int getCounter() {
return counter;
}
public synchronized int increment() {
return counter++; // counter++ is not atomic !
}
}
“Cheap Read-Write Lock” pattern
Readers
never block
Writers & vice
versa!

● equal in terms of visibility
○ Lock and volatile read are similar in their "acquire" action
○ Unlock and volatile write are similar in their "release" action
● Interchangeable only if:
○ Writes to volatile variable do not depend on its current value
○ Variable does not participate in invariants with other variables
28
volatile vs synchronized

● Volatile variables:
○ usually faster than locks
○ cannot cause a deadlock
○ lock-free semantics
○ simplicity
29

● Volatile variables:
○ not sufficient to
implement MT-safe
counters, mutex, or
multi-variable invariants
○ don't have wait/notify
semantics 30

def: safe publication -
everything written before
publication is visible
after
(un)safe publication

class A {
int f;
A() {f = 42;}
}
Thread 1 Thread 2
a = new A(); if (a != null)
println(a.f);
A a;
What does it print ?
(un)safe publication: toy(*)
(*) Courtesy of Aleksey Shipilёv

class A {
int f;
A() {f = 42;}
}
Thread 1 Thread 2
a = new A(); if (a != null)
println(a.f);
A a;
What does it print ? <nothing>, 0, 42, <throws NPE>

class A {
int f;
A() {f = 42;}
}
Thread 1 Thread 2
a = new A(); A ta = a;
if (ta != null)
println(ta.f);
A a;
What does it print ? <nothing>, 0, 42

public class UnsafeLazyInitialization {
private static Resource resource;
public static Resource getInstance() {
if (resource == null)
resource = new Resource(); // unsafe publication
return resource;
}
}
(un)safe publication
"Java Concurrency In Practice", Brian Göetz et al.

public class SafeLazyInitialization {
public synchronized static Resource getInstance() {
resource = new Resource(); // safe publication
return resource;
}
}
safe publication via synchronization

public class DoubleCheckedLocking {
if (resource == null) {
synchronized (DoubleCheckedLocking.class) {
resource = new Resource(); // publish
}
}
return resource;
}
}
Double-checked Locking

private static volatile Resource resource;
resource = new Resource(); // publish
}
}
return resource;
}
}
Double-checked Locking, fixed

private static volatile Resource[] resource;
public static Resource[] getInstance() {
resource = new Resource[42];
resource[0] = new Resource();
……………………………………………………………….…...
}
}
return resource;
}
}
DCL: is it still Ok ?

private static volatile List<Resource> resource;
public static List<Resource> getInstance() {
resource = new LinkedList<Resource>();
resource.add(new Resource());
……………………………………………………………….…...
}
}
return resource;
}
}
DCL: and this ?

DCL: what about this ?
Resource res = resource; // single volatile read
if (res == null) {
resource = new Resource();
}
res = resource;
}
}
return res; // non-volatile local read, a tiny bit better performance
}
}

public class ResourceFactory {
private static class ResourceHolder {
public static Resource resource = new Resource();
}
public static Resource getResource() {
return ResourceHolder.resource;
}
}
safe publication: Holder idiom & static initializer

public class MonoBean {
private T val;
public synchronized void setVal(T val) {
this.val = val;
}
public T getVal() {
return val;
}
}
setter + getter

private T val;
public synchronized void setVal(T val) {
this.val = val;
}
public synchronized T getVal() {
return val;
}
}
setter + getter

private volatile T val;
public void setVal(T val) {
this.val = val;
}
public T getVal() {
return val;
}
}
setter + getter

Final ﬁelds &
Safe
Initialization

● There is a synthetic freeze action at the
end of constructor, which "freezes" the
state of the final fields
● All threads see correct values of final
fields set by C'r
Final fields semantics
● Holds true for all dereference-chain: any field of any object
reachable through a final field is seen correctly by any
thread (in its “initial” state as it was constructed)
class A {
final int f;
A() {f = 42;}
}
freeze

● Immune to unsafe publications / races !
(if reference is visible through them)
● Reference to object should not escape C'r
before "freeze", otherwise no guarantees
provided
● Implemented as [LoadStore|StoreStore]
in Hotspot -> a single final field provides
final's visibility semantics to all class fields!
Final fields semantics
class A {
final int f;
A() {f = 42;}
}
freeze

Thread 1 Thread 2
a = new A(); A ta = a;
if (ta != null)
println(ta.f);
A a;
What does it print ? <nothing>, 42
safe initialization
freeze
Unsafe publication
class A {
final int f;
A() {f = 42;}
}

public class DCL {
synchronized (DCL.class) {
resource = new Resource();
}
}
return resource;
}
}
Recap: DCL
Volatile -> ﬁnal

Unsafe publication + safe initialization: 1st try
private static class R {
final T instance;
R(T t) {
this.instance = t;
}
}
} // UnsafeDCL
public class UnsafeDCL {
private static R resource;
public static T getInstance() {
synchronized (UnsafeDCL.class) {
resource = new R(new T());
}
}
return resource.instance;
}
What’s wrong ?

public class UnsafeDCL {
if (resource == null) { // race
synchronized (UnsafeDCL.class) {
}
}
return resource.instance; // race
}
Unsafe publication + safe initialization: 1st try
final T instance;
R(T t) {
this.instance = t;
}
}
} // UnsafeDCL
2 reads
is too much !!
2nd can be null

public class DCLWFinal {
R res = resource; // race
if (res == null) {
synchronized (DCLWFinal.class) {
}
res = resource;
}
}
return res.instance; // no race
}
final T instance;
R(T t) {
this.instance = t;
}
}
} // DCLWFinal
Now it’s ﬁne

4 Lazy
Singleton
Factories

Have already seen implementation
through:
1. Volatile field - DCL
2. Static field - Holder idiom
3. Final field - DCL w/ Local +
wrapper w/ final
4. Synchronized access to field
4 Lazy Singleton Factories
class B {
private A a;
public synchronized A get() {
if (a == null) {
a = new A();
}
return a;
}
}

Atomicity

JMM guarantees:
● reads and writes are atomic for
all built-in types, except long
and double
● volatile long and volatile double
are atomic
57
Atomicity

References

“Java Memory Model Pragmatics” by Aleksey Shipilёv
JMM fundamentals: Access atomicity, word tearing,
Sequential Consistency, Synchronization Order, SO-PO/SO
consistencies, Synchronizes-With Order, Happens-Before,
Sequential Consistency - Data Race Free, "Roach Motel", Out
of Thin Air values, Finals semantics, JMM9.
https://shipilev.net/blog/2014/jmm-pragmatics/

“Close Encounters of The Java Memory Model Kind”
by Aleksey Shipilёv
JMM fundamentals follow up. Common misunderstandings,
mistakes and misconceptions.
https://shipilev.net/blog/2016/close-encounters-of-jmm-kind

“Safe Publication and Safe Initialization in Java”
by Aleksey Shipilёv
JMM in everyday life. Singletons. Safe Publications & Safe
Initializations. Performance and memory costs.
https://shipilev.net/blog/2014/safe-public-construction/

Thanks to:
✗ SlidesWare by Google Slides
✗ Template by SlidesCarnival
http://www.slidescarnival.com
62
Credits

Practical Introduction to Java Memory Model

More Related Content

What's hot

Similar to Practical Introduction to Java Memory Model

Recently uploaded

Practical Introduction to Java Memory Model