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

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

(кстати, хорошим местом для многих параметров hotspot VM является на этой странице)

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

12
concurrency java jvm jvm-arguments

4 ответов

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

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

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

Я google-fu'Ed это из различных списков рассылки и JVM Багз:

12

butterchicken объясняет только половину истории, я хотел бы добавить больше деталей к ответу кматвеева. Да, опция предназначена для изменения состояния потока, и (псевдо) барьеры памяти используются для обеспечения того, чтобы изменение было видно из других потоков, особенно потока VM. Состояния потока, используемые в 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

4

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

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

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

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

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

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

2

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

1