Java Concurrency
Under The Hood

#volatile #membar #dragons #openjdk

#jmm #store #load #internals

#cachecoherency #omg

#javaone #jug

Leaky Abstractions

Each abstraction level obscures implementation details
Things that happen on lower levels affect high-level behavior
Some phenomena cannot be explained using high-level terms

void executedOnCpu0() {
    value = 10;
    finished = true;
}

void executedOnCpu1() {
    while(!finished);
    assert value == 10;
}

Can the assertion fail?

What if it's ran on x86?

The Theoretical Approach

According to JMM, it can fail without volatile
(but doesn't have to)
JMM only contains high-level abstractions
Doesn't say a word on x86 or any other architecture

Thus Spoke JMM

A write to a volatile variable

happens-before

All subsequent reads of that variable

A write to a volatile variable

synchronizes-with

All subsequent reads of that variable

Man... I don't know what you just said, but you're special, man.
You reached out, and you touched a brother's heart.

The Empirical Approach

Running the test once is not conclusive
Could run it lots of times ... a real lot!
If it still doesn't fail, then it probably shouldn't

Thou Shalt Not Reinvent The Wheel

The community has got it all covered
jcstress was created precisely for such research
Moreover, it contains just the test we need

`jcstress` demo

Test Results (x86)

y: 0, x: 3
y: 0, x: 0

y: 1, x: 0
y: 1, x: 3

Test Results (ARM)

y: 0, x: 3
y: 0, x: 0

y: 1, x: 0
y: 1, x: 3

Test Results (x86, C1)

y: 0, x: 3
y: 0, x: 0

y: 1, x: 0
y: 1, x: 3

Where Did The Abstractions Leak To?

    void executedOnCpu0() {
        value = 10;
        finished = true;
    }

↓

Nobody Wants To Be The Slow One

Each layer may apply some optimizations
Some optimizations may change the observed behaviour
Sometimes, it is perfectly acceptable
Some other times, it is not
The hardware engineers cannot know this in advance

For Instance: Cache Coherency

Accessing RAM is an expensive operation
A CPU has copies of frequently used data at hand
If there is more than one CPU, things can go awry

Variable	Cached Value
`finished`	`false`
`value`	N/A

Variable	Cached Value
`finished`	N/A
`value`	`0`

value = 10;

— Invalidate this!
...
...
— Done!

finished = true;

Had to wait for a long time
The CPU was stalled
Optimization time!

value = 10;

→

(executed asynchronously)

finished = true;

→

(likewise)

Why We Need A Memory Model

Software engineers know how their code is supposed to work
This must be relayed to the hardware
Memory Model is a trade-off between:
- How messed up writing code in a given language is
- How messed up a fast and correct language implementation is
- How messed up the hardware is
Aleksey Shipilёv

Memory Barriers

void foo() {
    value = 10;
    magicUnicorn();
    finished = true;
}

↛

void foo() {
    finished = true;
    magicUnicorn();
    value = 10;
}

(As seen by another thread)

The Two Types Of Memory Operations

Write

Read

Store

Load

ST

LD

They Should Not Be Treated Equally

Restricting all the reorderings is slow
Sometimes it's fine to reorder a Store and a Load
but not a Store and another Store
Need more fine-grained control
Let's introduce memory barriers of type XY
(X and Y take the values Store and Load)

For X, Y in [Store, Load]:

All X operations before an XY barrier

must complete before

Any Y operation after that barrier starts

Not Allowed

Allowed

Acquire And Release Semantice

The source of a synchronizes-with edge is called a release, and the destination is called an acquire

vstore(a.f, 1)

\---(sync-with)--->

vread(a.f, 1)

(source)

→

`javac`

(bytecode)

→

Frontend

(HIR)

→

JIT Optimizer

(LIR)

→

Backend

(native code)

→

...

(???)

→

PROFIT!

LIVE DEMO TIME!

Useful References

Papers:
- Memory Barriers: A Hardware View For Software Hackers
Blogs:
People are the best source: https://twitter.com/gvsmirnov/lists/java

Java Concurrency Under The Hood