rfqcdtyjvВ ней сказано: " мы не знаем, что вы там увидите ". Может быть старое значение, может быть новое значение, может быть это будет мусорный результат спекуляции, может это будет мусорный результат неатомарной записи long/double значения, да что угодно это может быть.
В каком месте это сказано?Более глубокое изучение JMM показало следующее:
1) JMM запрещает out-og-thin-air значения даже для некорректно синхронизированных программ. Формально это означает, что если я читаю X, то прочитанное мной значение обязательно должно было быть _честно_ записано туда ранее. Так как спекулятивные записи к _честным_ не относятся, то чтение спекулятивных значений в JMM запрещено. Формально это описано вот в этой главе JLS - http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4.8 . А более человеческим языком вот здесь - http://cseweb.ucsd.edu/classes/fa05/cse231/Fish.pdf .
2) При всем при этом, как мы знаем, JMM допускает неатомарные записи long/double. То есть, если у меня был long, иниициализированный нулем, один тред записал туда 0xffffffff00000000, а другой 0x00000000ffffffff, то третий поток может увидеть не три, а четыре значения: 0, 0x00000000ffffffff, 0xffffffff00000000 и 0xffffffffffffffff .

Лично я не вижу отличий между тем, что поток увидит какое-то левое значение, из-за того, что две одновременные записи long "наложились" друг на друга, и тем, что поток увидит спекулятивную запись, которая потом будет откачена. А JMM эти два случая разделяет. То есть, неатомарная запись long/double, это по логике вещей вроде бы out-of-thin-air, а вроде бы и нет.
Собственно, поэтому я и настаивал на том, что чтение спекулятивной записи не запрещено, ибо я не вижу разницы между этими двумя случаями.

Как это понять - хз. Думаю, здесь спасет разве что письмо в concurrency-interest в надежде услышать ответ от отцов-основателей JMM. Что я сегодня и сделаю, а потом напишу ответ на Хабре, ибо жесть.

После тяжелых дум я таки разобрался в вопросе. Итого:
1) Принципиальное отличие между word tearing (т.е. когда мы засрали long/double конкурирующими неатомарными записями) принципиально отличается от гипотетической ошибочной спекулятивной записи тем, что результат word tearing может оставаться актуальным неограниченно долго, а спекулятивная ошибка eventually будет откачена. Таким образом, результат word tearing можно рассматривать, как результат нормального store commit, и его нельзя отнести к out-of-thin-air в том значение, которое использует JMM.
2) Тем не менее, наличие out-of-thin-air результатов не является препятствием для создания рабочих моделей памяти. Пример - модель памяти C++11. Изначально она допускала такое. В 2012 пошли разговоры о том, что бы пойти путем Java, и запретить это ( http://preshing.com/20120625/memory-ordering-at-compile-time/ ). Чем в итоге кончилось - не знаю.
3) Мотивация создателей JMM по запрету out-of-thin-air значений была по сути одна - безопасность. Так как Java ставит security во главу угла (а мы на нее постоянно благополучно кладем. отключая SecurityManager ), ситуация, когда мы можем увидеть какое-то непонятное значение недопустима, так как этим "смотрящим" может быть не-trusted код, а "непонятным значением" может оказаться какой-нибудь пароль. А мы хотим, что бы даже те программисты, которые незнакомы с JMM, могли писать по возможности максимально безопасный код.