Что такое параметр Java -XX: + UseMembar

Question

Я вижу этот параметр во всех видах мест (форумах и т. Д.) И общий ответ на него помогает серверам с высокой степенью одновременности Тем не менее, я не могу найти официальную документацию от Sun, объясняющую, что она делает. Кроме того, он был добавлен в Java 6 или существовал в Java 5?

(Кстати, хорошим местом для многих параметров виртуальной машины в точке доступа является эта страница )

Обновление: Java 5 не загружается с этим параметром.

Answer 1

Чтобы оптимизировать производительность, JVM использует в коде «барьер псевдопамяти», чтобы выступать в качестве инструкции по ограждению при синхронизации между несколькими процессорами. Можно вернуться к «истинной» инструкции барьера памяти, но это может оказать заметное (и плохое) влияние на производительность.

Использование -XX:+UseMembar заставляет виртуальную машину возвращаться к истинным инструкциям барьера памяти. Первоначально этот параметр предназначался для временного существования в качестве механизма проверки новой псевдобарьерной логики, но оказалось, что новый барьерный код псевдо-памяти привел к некоторым проблемам синхронизации. Я считаю, что теперь они исправлены, но до тех пор, пока они не были устранены, приемлемым способом решения этих проблем было использование восстановленного флага.

Ошибка была введена в 1.5, и я считаю, что флаг существует в 1.5 и 1.6.

Я отгадал это из множества списков рассылки и ошибок JVM:

• http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6546278
• Обязательная ссылка Википедии на барьеры памяти (инструкции по фехтованию)
• Классический пост от Раймонда Чена
• ТАК вопрос по фехтованию

Answer 2

butterchicken только объясняет половину истории, я хотел бы добавить более подробную информацию к ответу kmatveev. Да, эта опция предназначена для изменения состояния потока, и (псевдо) барьеры памяти используются, чтобы гарантировать, что изменение видно из других потоков, особенно потока ВМ. Состояния потоков, используемые в OpenJDK6, следующие:

//  _thread_new         : Just started, but not executed init. code yet (most likely still in OS init code)
//  _thread_in_native   : In native code. This is a safepoint region, since all oops will be in jobject handles
//  _thread_in_vm       : Executing in the vm
//  _thread_in_Java     : Executing either interpreted or compiled Java code (or could be in a stub)
...
 _thread_blocked           = 10, // blocked in vm   

Без опции UseMembar в Linux Hotspot использует страницу сериализации памяти вместо инструкции барьера памяти. Всякий раз, когда происходит переход состояния потока, поток записывает на адрес памяти в странице сериализации памяти с изменчивым указателем. Когда потоку виртуальных машин необходимо проверить текущее состояние всех потоков, виртуальная машина изменяет защитные биты для страницы сериализации памяти только для чтения, а затем восстанавливает ее для чтения / записи для сериализации изменений состояния. Более подробный механизм представлен на следующей странице:

http://home.comcast.net/~pjbishop/Dave/Asymmetric-Dekker-Synchronization.txt

Answer 3

UseMembar определяет, следует ли строго использовать инструкции мембраны, заставляя все действия с памятью завершать перед продолжением.

Это в основном не позволяет обработчикам с задержкой обработки памяти связываться с кодом.

Обычно это замедляет работу и не требуется на современных виртуальных машинах для подавляющего большинства кода.

Иногда вы сталкиваетесь с проблемами, когда код ДОЛЖЕН быть поточно-ориентированным, но не из-за отсутствия использования инструкций мембраны. В этих случаях вы можете включить это, чтобы заставить такой код работать, не переключаясь на однопоточность или возиться с порядком кода, чтобы предотвратить проблему.

JVM, как правило, хорошо обнаруживает код, который может вызвать проблемы, и либо вставляет мембрану, либо выполняет оптимизацию перестановки кода JIT, чтобы обеспечить время для выполнения операций с памятью. Фактически, в моем веб-поиске по этой теме я обнаружил только один пример ошибки, и она была исправлена ​​в последних версиях Oracle и OpenJRE версий JVM горячей точки.

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

Answer 4

Я не согласен с ответом от butterchicken. Эта страница http://www.md.pp.ru/~eu/jdk6options.html говорит, что этот флаг вызывает выдачу барьеров памяти, а затем поток меняет свое состояние (например, с RUNNABLE на WAITING или на BLOCKED).