Javaの-XXとは+ + UseMembarのパラメータ

Question

このパラメータはあらゆる種類の場所（フォーラムなど）で表示され、一般的な回答は高度に並行したサーバーに役立ちます。それでも、私は太陽からそれが何をしているかを説明する正式な文書を見つけることができません。また、Java 6で追加されたのですか、それともJava 5で存在しましたか？

更新（ところで、多くのホットスポットVMパラメータのために良い場所はthis pageです）： Java 5のこのパラメータを指定して起動しません。

Answer 1

パフォーマンスを最適化するために、JVMはコード内に「疑似メモリバリア」を使用して、複数のプロセッサ間で同期をとるときにフェンシング命令として機能します。 「真の」メモリバリア命令に戻すことは可能ですが、パフォーマンスに顕著な（悪い）影響を与える可能性があります。

-XX:+UseMembarを使用すると、VMは真のメモリバリア命令に戻ります。このパラメータはもともとは新しい擬似バリアロジックの検証メカニズムとして一時的に存在することを意図していましたが、新しい擬似メモリバリアコードによって同期の問題がいくつか導入されました。私はこれらが今修正されていると信じていますが、それが実現するまで、これらの問題を回避するために受け入れられる方法は、復活旗を使用することでした。

このバグは1.5に導入されました。私はこのフラグが1.5と1.6に存在すると確信しています。

私はメーリングリストやJVMのバグの様々なからこのGoogle-fu'edました：

• http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6546278
• The obligatory Wikipedia link to memory barriers (fencing instructions)
• A classic post from Raymond Chen
• SO question on fencing

Answer 2

Iドンバターチキンの答えに同意しない。このページ http://www.md.pp.ru/~eu/jdk6options.html は、このフラグによってメモリバリアが発行され、スレッドの状態がRUNNABLEからWAITINGまたはBLOCKEDに変更されることが示されています。

Answer 3

バターチキンは物語の半分しか説明しません、私はkmatveevの答えにもっと詳しく説明したいと思います。そうです。オプションはスレッド状態の変更であり、（擬似）メモリバリアは、変更が他のスレッド、特に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では、ホットスポットではなく、メモリバリア命令のメモリシリアライズ・ページを使用しています。スレッド状態遷移が起こるたびに、スレッドはメモリ内のメモリアドレスに書き込み、揮発性ポインタを有するページを直列化する。 VMスレッドがすべてのスレッドの最新の状態を調べる必要がある場合、VMは、メモリシリアライズページの保護ビットを読み取り専用に変更し、それを読み取り/書き込みして状態変更をシリアライズするように回復します。より詳細なメカニズムは以下のページで紹介している：

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

Answer 4

UseMembarは続行する前に完了するために、すべてのメモリの動作を強制的に、厳密な方法でMEMBAR命令を使用するか否かを判断します。

これは基本的に、プロセッサの遅延メモリ処理を中止して、最適化を行うことでコードが煩雑にならないようにします。

これは一般的に物事を遅くし、大部分のコードで現代のVMでは必要ない。

コードはスレッドセーフでなければならない場合がありますが、membar命令の使用が不足しているためではありません。このような場合には、これをオンにすると、シングルスレッドに切り替えることなく、または問題を防ぐためにコードの順序を変えずに、そのようなコードを動作させることができます。

JVMは一般的に問題を引き起こすコードを検出し、membarを挿入するか、JITコードの並べ替えの最適化を行い、メモリ操作の完了に時間を要します。実際、トピックに関する私のウェブ検索では、バグの一例しか見つからず、OracleとOpenJREバージョンのホットスポットJVMの両方の最新バージョンで修正されました。

注：ARMアーキテクチャの場合、代替オプション（擬似体膜最適化とも呼ばれます）がまだ適用されていないため、このオプションはデフォルトでonに設定されていますので、membar命令なしでは非常にバグがあります。