0FD ,
Я ничего не ожидаю, я лишь демонстрирую, как разные способы чтения влияют на то, завершится программа или нет.

schwaТолько вот с тем, что это код будет ломаться никто и не спорил ;)Ну вы же сказали, что при обращении к "общим" локациям памяти все будет нормально. Как видно из кода, не будет.

schwaНевезение с гуглом. Мне он выдает цитаты из соответствующих мануалов в первых же результатах поиска.Поделитесь ссылочкой.

rfqНет, не может. Все сделано так, что для программиста нет разницы, делал процессор спекулятивное выполнение или нет - разве что общее время получается разным.Ну вот кто вам такое сказал? Даже если процессор спекулятивно пошел по ошибочному бранчу, и начал что-то писать, это вовсе не значит, что sequential consistency сломается в потоке, в котором эта спекуляция произошла. Тем не менее, большинство (если не все) распространенных процессоров так не делают. Не потому, что это невозможно в принципе, а потому что просто инженеры решили пойти другим путем. Вот, что написано в одной из диссертаций ( http://www3.ece.neu.edu/~yilmazer/thesis/thesis.pdf) на эту тему:
AYSE YILMAZERTo maintain the illusion of sequential consistency, a store instruction cannot write its value to memory until it becomes the oldest (i.e., non-speculative) instruction in the processor.То есть да, пока мы не узнаем гарантированно, что данный бранч не является спекулятивным, мы не будем писать это в память. А следовательно, другие потоки не увидят спекуляцию. НО! Далее идет следующее замечание:
AYSE YILMAZERIn this study, we did not consider the multiprocessors based on uniprocessors that may speculatively execute store instructions, such as the speculative versioning cache of Multiscalar [22], or Levo [24].О как оно оказывается. Есть процессоры, которые могут спекулятивно писать в память. И если вы сейчас сидите на каком-нибудь Интеле, который это не делает, это не означает, что следующее поколение их же процессоров этого делать не будет.

В десятый раз поторюсь: рассуждать на тему того, что именно может делать какой-то абстрактный процессор в вакууме, это все от лукавого.

rfqТем не менее, речь-то идет о Java, и даже если она будет портирована на подобные экзотические процессоры, я думаю, что спекулятивная запись в память будет зарублена. Во всяком случае, я сомневаюсь, что такая запись в память допускается спецификацией JVM.Спецификация JVM не оперирует такими понятиями, как "спекулятивная запись" в принципе. JVM для корректной работы нужно две вещи:
1) Sequential consistency по умолчанию для одного потока - что бы работали однопоточные программы;
2) Sequential consistency _по_требованию_ для нескольких потоков - что бы работали многопоточные программы.

Что здесь интересно? Если будет отсутствовать п.1, то у вас не будет работать не только JVM, но и все остальные современные приложения. Ибо без sequential consistency запрограммировать что-либо можно только в теории, но не практике.

А если будет отсутствовать п.2, то у вас не будет работать не только JVM с несколькими потоками, но и все остальные современные приложения. Ибо что из себя представляют понятия, из того же JSR133 Cookbook? Всякие там StoreLoad и иже с ними? Это просто логичесике обертки над какими-то физическими инструкциями процессора и правилами компилятора. Не более того. Если для этих логических оберток нет конкретных решений на конкретной платформе, значит она не предназначена для многопоточной работы в принципе.

schwaА точно программа это поведение сможет обозреть, если вместе с введением этих оптимизаций идут правки в протоколы конгерентности кэшей и др. ? Просто в противном случае подобная оптимизация может сломать даже корректную программу.Вопрос лишен смысла. Я могу с таким же успехом спросить: "А точно ли текущая модель работы с памятью x86 работает правильно?" Теоретически, она может работать правильно. Работает ли она правильно по факту - не знаю.
Так же и со спекулятивными записями. Может ли такой подход работать теоретически? Да, может. Работает ли он корректно в конкретном экземпляре Multiscaler/Levo? Не знаю.

schwaЭтот вопрос лишен смысла только для тех, кто не видит разницы между вычитываем старого значения и выполнением участков кода, которые выполнится никак не могли вообще ибо они используют значение, которые никакими операциями, которые выполнялись в программе получено не было.Ничего не понял, сформулируйте свой вопрос еще раз.
Вот мы спекулятивно предположили, что значение calc() вернет true, и пошли в соответствующий бранч. В этом бранче вы выполняем какие-то операции. Потом мы узнали, что calc() на самом деле вернул false. Окей, мы берем и откатываем те изменения, которые успели нагородить, и заново выполняем код с того момента, когда мы сделали ошибочное предположение.
Это не какие-то мои додумки, так работают все современные процессоры, почитайте любой мануал, ключевое слово - "speculative branch prediction".

НО! Современные процессоры не допускают спекулятивные записи в кэш. Они спекулятивно меняют значения только в рамках регистров процессора. А те архитектуры, что я указал выше, могут записать спекулятивное значение и в свой кэш, и даже в кэш другого ядра. И это будет работать до тех пора, пока данные изменения можно откатить. А откатить их можно.

И с точки зрения sequential consistency в рамках одного потока, абсолютно пофиг, где сейчас находятся спекулятивные (то есть потенциально некорректные) значения - в регистрах, в кэшах, или где-либо еще. Потому я и не могу понять, что вы хотите донести.

P.S.: Я надеюсь, что все понимают, что когда я говорю "начал спекулятивно выполнять бранч" != "начал спекулятивно выполнять все инструкции в этом бранче". Спекулятивно можно выполнять только то, что можно откатить. Поэтому, например, никто не будет спекулятивно джампить System.out.println(), так как в случае ошибки мы это не сможем откатить. Спекулятивно выполняются только те инструкции, ущерб от которых конкретный процессор сможет компенсировать.

rfqЛюбая реализация JVM на каком угодно процессоре должна вести себя одинаково.Кто вам это сказал? Где это написано в спецификации? Они должны вести себя одинаково в рамках JMM. А JMM ничего не говорит ни о реордерингах, ни о кэшах, ни о чем-либо подобном. Она лишь дает набор правил, которым должна следовать JVM. И одно из этих правил, например, гласит: volailte чтение, следующее после volatile записи, гарантированно увидит результат этой записи. То есть, вам дают гарантию, что вы увидите что-то определенное, после того, как предпримете определенные шаги (в данном случае - обеспечите волатильное чтение, которое гарантированно идет после волатильной записи).


rfqРаз интерпретатор, сделанный по букве спецификации, никогда не записывает мусорные значения в память, которые могут быть замечены другим потоком, то и все остальные реализации не должны этого делать.Это что еще за глупость? Покажите мне, где в спецификации написано, что "интерпретатор не записывает мусорные значения в память". Можете сслыку на это привести? Думаю нет, так как это плод вашей фантазии, который к реальности отношения не имеет.
JMM говорит нам: если один поток записал что-то в переменную, то мы не можем ничего сказать, что увидит другой поток. В спецификации не сказано "вы увидите актуальное значение". В ней не сказано "вы увидите старое значение". В ней сказано: " мы не знаем, что вы там увидите ". Может быть старое значение, может быть новое значение, может быть это будет мусорный результат спекуляции, может это будет мусорный результат неатомарной записи long/double значения, да что угодно это может быть. Мы не даем никаких гарантий. Хотите быть в чем-то уверенными? Тогда вот вам synchronized-with, вот вам исключение в лице final - в этих случаях у вас будут гарантии, что вы увидите ровно то, что должны увидеть.

Еще раз, что бы уж точно усвоилось: выбор идет не между "старым" и "актуальным", а между "актуальным" и "не актуальным". А что такое "не актуальное" спецификация не говорит .