Финальные поля Java на x86 нет оп?

Мне всегда нравилось копаться в деталях многопоточного программирования, и мне всегда нравилось, что, несмотря на долгие годы чтения о моделях согласованности памяти ЦП, алгоритмах без ожидания и без блокировки, модели памяти java, параллельности java на практике и т. Д. и т.д. — я все еще создаю ошибки многопоточного программирования. Это всегда удивительно унизительный опыт, который напоминает мне, насколько сложна эта проблема.

Если вы читали JMM, то, возможно, помните, что одной из областей, которую они усилили, была гарантия видимости конечных полей после завершения конструктора. Например,

JMM заявляет, что каждый поток (даже потоки, отличные от того, который создал экземпляр x класса ClassA)
всегда отмечайте xb как «привет» и никогда не увидите значение null (значение по умолчанию для ссылочного поля).

Это действительно здорово! Это означает, что мы можем создавать неизменяемые объекты, просто помечая поля как окончательные, и любой созданный экземпляр автоматически может быть разделен между потоками без какой-либо другой работы, чтобы гарантировать видимость памяти. Woot! Обратной стороной этого является то, что если бы ClassA.b не был помечен как окончательный, то у вас не было бы такой гарантии. И другие потоки могли наблюдать нулевой результат xb == (если никакие другие механизмы «безопасной публикации» не использовались для получения видимости)

Когда они создали новый JMM, любимый участник JCP, Дуг Ли, создал кулинарную книгу, чтобы помочь разработчикам JVM реализовать новые правила модели памяти. Если вы прочитаете это, то увидите, что «правила» гласят, что JIT-компиляторы должны испускать барьер памяти StoreStore , прямо перед возвращением конструктора. Этот барьер StoreStore является своего рода «забором памяти». Когда указывается в инструкциях по сборке, это означает, что никакие операции записи (сохранения) в память после перегородки не могут быть переупорядочены до того, как операции записи в память появятся перед ограничителем. Обратите внимание, что это ничего не говорит о чтениях — они могут «прыгать» забор в любом направлении.

Так что это значит? хорошо, если вы думаете о том, что делает компилятор, когда вы вызываете конструктор:

Барьер StoreStore на шаге 4 гарантирует, что любые записи (такие как метаданные класса и поле b) не будут переупорядочены с записью в x на шаге 5. Это то, что гарантирует, что если x виден любым другим потокам — что этот другой поток не может видеть x и без xb. Без барьера памяти StoreStore шаги 3 и 5 можно переупорядочить, и запись в основную память для x может появиться перед записью в xb и другим процессором. ядро может наблюдать, что pointer_to_A.b равен 0 (нулю), что нарушает JMM.

Отличные новости! Однако, если вы посмотрите на эту кулинарную книгу, вы увидите некоторые интересные вещи: (1) многие люди пишут JVM на множестве процессорных архитектур! (2) * Все * барьеры памяти на x86 не являются операционными, кроме барьера StoreLoad! Это означает, что на x86 вышеупомянутый барьер памяти StoreStore не используется, и поэтому для него не создается сборка. Это ничего не делает! Это связано с тем, что модель памяти x86 представляет собой строгий «общий порядок магазинов» (TSO). X86 следит за тем, чтобы все записи в память наблюдались так, как если бы они были выполнены в одном и том же порядке. Таким образом, запись 5 никогда не будет появляться перед 3 в любом другом потоке в любом случае из-за TSO, и нет необходимости создавать ограничение памяти. Другие архитектуры ЦП имеют более слабые модели памяти, которые не дают таких гарантий, и, таким образом, необходим ограничитель памяти StoreStore. Обратите внимание, что более слабые модели памяти, хотя, возможно, сложнее или менее интуитивно понятны для программирования, как правило, гораздо быстрее, поскольку процессор может переупорядочивать объекты, чтобы более эффективно использовать записи в кэш и снижать согласованность работы кеша.

Очевидно, вы должны продолжать писать правильный код, следующий за JMM. НО это также означает (к сожалению или к счастью), что забывание этого не приведет к ошибкам, если вы работаете на x86 … как я делаю на работе.

Чтобы по-настоящему раскрыть этот дом и убедиться, что нет других побочных эффектов, которые, возможно, не описаны в кулинарной книге, я запустил средство вывода сборки x86, как описано здесь, и записал результат вызова конструктора для ClassA (с последним на поле ссылочного типа) и конструктор для ClassB, который был идентичен ClassA, за исключением последнего ключевого слова в классе. Выход сборки x86 идентичен . Таким образом, с точки зрения JIT, на x86 (не itanium, не arm и т. Д.) Последнее ключевое слово не оказывает влияния.

Если вам интересно, как выглядит ассемблерный код здесь, он ниже. Обратите внимание на отсутствие каких-либо заблокированных инструкций. Когда Oracle 7u25 JRE испускает ограничение памяти StoreLoad x86, это делается с помощью генерации блокировки addl $ 0x0, (% rsp), которая просто добавляет ноль к указателю стека — без операции, но, поскольку она заблокирована — это имеет эффект полного забор (который соответствует критериям забора StoreLoad). В x86 есть несколько разных способов вызвать эффект полного забора, и они обсуждаются в списке рассылки OpenJDK. Они заметили, что, по крайней мере, в Nehelem Intel добавление блокировки 0 было наиболее компактным / эффективным.