Многопоточность Java
Под Капотом

#volatile #membar #dragons #openjdk

#jmm #store #load #internals

#cachecoherency #omg

#jpoint #jpoint2014

#jugru #jugmsk

bullshit-bingo.ru/card/199

Текущие Абстракции

Каждый слой абстракции прячет детали реализации
Происходящее на нижних уровнях влияет на высокоуровневое поведение
Некоторое поведение нельзя объяснить в рамках абстракции

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

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

Может ли упасть?

А на x86?

Подход Теоретический

Согласно JMM, без volatile упасть может
(а может и не упасть)
В JMM есть только высокоуровневые абстракции
Нет ни одного слова про x86 или другие архитектуры

Так Говорила JMM

Запись значения в volatile поле

happens-before

Последующее чтение значения из этого поля

Запись значения в volatile поле

synchronizes-with

Последующее чтение значения из этого поля

Чувак, я ничего не понял из того, что ты сейчас сказал.
Но ты заговорил и достучался моего до сердца.

Подход Эмпирический

Один запуск не даст надёжных результатов
Можно запустить много раз ... очень много раз!
Если так и не упадёт, то, вероятно, и не должно

Не Сотвори Себе Велосипеда

Сообщество уже сделало всё за нас
jcstress создан специально для таких изысканий
И там даже есть нужный тест

Демо `jcstress`

Результаты Теста (x86)

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

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

Результаты Теста (ARM)

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

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

Результаты Теста (x86, C1)

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

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

Куда Протекли Абстракции?

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

↓

Никто Не Хочет Быть Тормозом

На каждом слое могут применяться оптимизации
Есть оптимизации, меняющие наблюдаемое поведение
Иногда это вполне допустимо (но иногда — нет)
Разработчики среды не знают этого заранее

Когерентность Кешей, Например

Доступ к основной памяти — дорогая операция
Ядра хранят копии популярных значений поблизости
Если ядер более одного, начинается дикий угар

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

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

value = 10;

— Удали из кеша!
...
...
— Я удалил!

finished = true;

Пришлось ждать очень долго
Процессор простаивал
Вы — самое слабое звено!
Время оптимизировать

value = 10;

→

(исполняется асинхронно)

finished = true;

→

(тоже)

Модель Памяти — Нужна

Разработчики софта знают, как должна вести себя программа
Нужно передать это знание среде исполнения
Модель памяти = trade-off между:
- Долбанутостью программирования на языке
- Долбанутостью быстрой и корректной реализации языка
- Долбанутостью хардвара
Алексей Шипилёв

Барьер Памяти

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

↛

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

(С точки зрения другого потока)

Есть Два Типа Операций с Памятью

Запись

Чтение

Store

Load

ST

LD

Не Всех Под Одну Гребёнку

Запрещать переставлять всё со всем — медленно
Иногда допустимо переставить ST и LD, но не ST и ST
Нужен более тонкий контроль
Введём барьеры памяти типа XY
(X и Y принимают значения Store и Load)

For X, Y in [Store, Load]:

Все операции типа X перед барьером типа XY

завершатся до того, как

Начнётся любая операция типа Y после этого барьера

Так Делать Нельзя

Зато Можно Так

Семантика Acquire и Release

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)

(исходник)

→

`javac`

(байт-код)

→

Frontend

(HIR)

→

JIT-Оптимизатор

(LIR)

→

Backend

(нативный код)

→

...

(???)

→

PROFIT!

LIVE DEMO TIME!

Полезные Материалы

Работы:
- Memory Barriers: A Hardware View For Software Hackers
Блоги:
Люди ‐ наше всё: https://twitter.com/gvsmirnov/lists/java

Многопоточность Java Под Капотом