No video

Java Memory Model Pragmatics (Aleksey Shipilёv, Russia), part 2

  Рет қаралды 10,327

jeeconf

jeeconf

Күн бұрын

Java Memory Model (JMM) specification tries to be very concise yet complete. Because JMM tries to embrace a very large set of phenomenon, its formalism is very heavy, which unfortunately resulted in losing the “humanity” of the spec.
In this talk, we will follow the logic of the model; review what pragmatic results the model was trying to achieve; look closely at the real world limitations the model had to endure; see how JMM tries to balance between developers’ needs and runtime/hardware maintainers requests.

Пікірлер: 6
@acidelk
@acidelk 4 жыл бұрын
Возможно ли воспроизвести кейс с частичной инициализацией (20:30) на x86? Пытался добиться (в этом примере) x==0, но так и не смог... Если ссылка утечет из конструктора наружу, то все понятно, но в данном кейсе не могу понять...
@germanberezhko1050
@germanberezhko1050 8 жыл бұрын
на 20:28 объясните про NPE, пожалуйста
@waliot_cto
@waliot_cto 8 жыл бұрын
docs.oracle.com/javase/7/docs/api/java/lang/NullPointerException.html
@POWERon4ik
@POWERon4ik 8 жыл бұрын
на сколько я понимаю, в println(a.f), a заново читается, и это отдельная операция, а jvm может это чтение вынести за то чтение которое произошло для if-а. Т.е. может быть такой порядок r1 = a; //тут а еще null r2 = a; //тут уже все ок if (r2 != null) { _//предполагается что r1 = a должно быть здесь ___r3 = r1.f; // NPE ___println(r3); }
@maksymkoval1754
@maksymkoval1754 6 жыл бұрын
В ARM при чтении в регистры поток может реордерить чтения. Записывая в local ты гарантируешь, что ты работаешь ровно с одной переменной, а не с двумя, которые сделали два независимых чтения. Будет два разных чтения, но в x86/64 это не приведет к проблеммам т.к. оно прочитает по прядку (если конечно нет ничаких оптимизаций -- а они не ломают JMM). К слову Java может "склеить" два одинаковых чтения в одно чтение (но это вариант оптимизации).
@landaumanify
@landaumanify 5 жыл бұрын
out of thin air запрещены, поэтому мы можем прочитать там только то, что потенциально могли видеть в программе: либо 0 (дефолтное значение ф до выполнения конструктора), 42 или нпе из-за того, что а еще не успел проинититься. А почему мы можем прочитать налл во втором чтении после ифа? Потому что модель памяти в теории это позволяет сделать, а значит на каком-то железе, жвм или компиляторе теоретически такая ситуация возможна. Понятное дело, что на х86 с его встроенным loadload барьером эту ситуация вряд ли можно встретить будет, но в теории такое возможно. Мы же говорим о модели и ее ограничениях, а не о конкретных реализациях. Но даже на х86 компиль или джит вполне могут что-то сделать, что приведет к подобному исполнению
Алексей Шипилёв - Прагматика Java Memory Model
1:55:22
JPoint, Joker и JUG ru
Рет қаралды 121 М.
Алексей Шипилёв - Performance Optimization 101
44:50
JPoint, Joker и JUG ru
Рет қаралды 17 М.
WHO CAN RUN FASTER?
00:23
Zhong
Рет қаралды 44 МЛН
КАКУЮ ДВЕРЬ ВЫБРАТЬ? 😂 #Shorts
00:45
НУБАСТЕР
Рет қаралды 3,3 МЛН
Schoolboy Runaway в реальной жизни🤣@onLI_gAmeS
00:31
МишАня
Рет қаралды 3,4 МЛН
Parenting hacks and gadgets against mosquitoes 🦟👶
00:21
Let's GLOW!
Рет қаралды 13 МЛН
Алексей Шипилёв - Сжимай меня полностью
55:20
JPoint, Joker и JUG ru
Рет қаралды 13 М.
14. JAVA. Memory Model | Технострим
30:20
VK Team
Рет қаралды 41 М.
Алексей Шипилёв - Близкие Контакты JMM-степени
57:49
Benchmarking for Good with Aleksey Shipilev
51:14
Java
Рет қаралды 2,7 М.
Test Driven Architecture (Peter Gafert, Germany)
56:33
jeeconf
Рет қаралды 1,4 М.
WHO CAN RUN FASTER?
00:23
Zhong
Рет қаралды 44 МЛН