JVMオプション。 仕組み

毎日、javaという言葉は言語としてではなく、悪名高いinvokeDynamicのおかげでプラットフォームとして認識されています。 それが、今日、仮想Javaマシン、つまりOracle HotSpot JVMバージョン1.6以降（サーバー）のいわゆるパフォーマンスオプションについてお話ししたい理由です。 今日、-Xmx、-Xms、-Xss以外のことを知っている人に会うことはほとんど不可能だからです。 ある時、私がこのトピックを掘り下げ始めたとき、私は共有したい膨大な量の興味深い情報を発見しました。 もちろん、出発点はオラクルの公式ドキュメントです。 そしてグーグル、実験、コミュニケーション：

-XX：+ DoEscapeAnalysis

おそらく、最も興味深いオプションであるDoEscapeAnalysisから始めましょう。 多くの人が知っているように、プリミティブとオブジェクト参照はヒープ上に作成されるのではなく、ストリームスタック上に割り当てられます（Hotspotのデフォルトでは256KB）。 Java言語では、スタック上にオブジェクトを直接作成できないことは明らかです。 ただし、JVM 1.6は、14回目のアップデート以降、それ自体でこれを実行できます。

アルゴリズム自体の仕組みについては、 こちら（PDF）をご覧ください 。 要するに：

• オブジェクトのスコープが作成されたメソッドを超えない場合、そのようなオブジェクトはヒープの代わりにスタックフレーム上に作成できます（実際、オブジェクト自体ではなく、オブジェクトが置き換えられるフィールド全体）;
• オブジェクトがストリームのスコープを離れない場合、他のストリームはそのようなオブジェクトにアクセスできないため、オブジェクトのすべての同期操作を削除できます。

このアルゴリズムを実装するために、いわゆる接続グラフが構築され、使用されます。これに従って、分析の段階（いくつかの分析アルゴリズム）で、他のフローやメソッドとの交差点を見つけるための通路が作られます。
したがって、オブジェクトのリンクグラフを渡すと、次のいずれかの状態が可能になります。

• GlobalEscape-オブジェクトは、他のストリームおよび他のメソッド（静的フィールドなど）からアクセスできます。
• ArgEscape-オブジェクトは引数として渡された、または引数オブジェクトからオブジェクトへのリンクがありますが、それ自体は作成されたストリームの範囲から出ません。
• NoEscape-オブジェクトはメソッドのスコープを離れず、その作成はスタックにプッシュできます。

分析段階の後、JVM自体はすでに可能な最適化を行っています。NoEscapeオブジェクトの場合、スタック上に作成できます。 オブジェクトがNoEscapeまたはArgEscapeの場合、そのオブジェクトに対する同期操作は削除できます。

オブジェクト自体ではなく、そのフィールドがスタック上に作成されることを明確にする必要があります。 JVMはオブジェクト全体をそのフィールドの全体に置き換えます（明確にするためにWalrusに感謝します）。

この種の分析のおかげで、プログラムの個々の部分のパフォーマンスが大幅に向上することは明らかです。 合成テストでは、次のようになります。

for (int i = 0; i < 1000*1000*1000; i++) { Foo foo = new Foo(); } 

実行速度は8〜15倍になります。 しかし、最近書かれた（ こことここで ）練習からの一見明らかなケースでは、EscapeAnalysは機能しません。 これはスタックのサイズによるものと思われます。

ちなみに、EscapeAnalysisは、StringBuilderとStringBufferについてよく知られている紛争の一部を担っています。 つまり、メソッドでStringBuilderではなくStringBufferを突然使用した場合、EscapeAnalysis（トリガーされた場合）はStringBufferのロックを解除し、その後、StringBufferは完全にStringBuilderに変わります。

-XX：+ AggressiveOpts

AggressiveOptsオプションはスーパーオプションです。 アプリケーションのパフォーマンスを劇的に向上させるという意味ではなく、他のオプションの値のみを変更するという意味では（実際、これは完全に真実ではありません-JDKソースコードにはAggressiveOptsがJVMの動作を変更する場所がかなりあります） 、前述のオプションに加えて、 ここの例の1つです ）。 2つのコマンドを使用して、変更されたフラグを確認します。

 java -server -XX:-AggressiveOpts -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal > no_aggr java -server -XX:+AggressiveOpts -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal > aggr 

実行後、コマンドの実行結果の違いは次のようになりました。

	-AggressiveOpts	+ AggressiveOpts
AutoBoxCacheMax	128	20000
BiasedLockingStartupDelay	4000	500
EliminateAutoBox	偽	本当
OptimizeFill	偽	本当
OptimizeStringConcat	偽	本当

つまり、このオプションが行うことは、仮想マシンの5つのデータパラメーターを変更することだけです。 さらに、バージョン1.6アップデート35および1.7アップデート7では、違いは認められませんでした。 このオプションはデフォルトで無効になっており、クライアントモードでは何も変更されません。
積極的な最適化によるjavaの意味を検討してください。

-XX：AutoBoxCacheMax =サイズ

仮想マシンの起動時に、整数型のキャッシュ値の範囲を拡張できます。 このオプションについてはすでに説明しました（2番目の段落） 。

-XX：BiasedLockingStartupDelay = delay

ご存じのとおり、Javaの同期ブロックは、次の3種類のロックのいずれかで表すことができます。

• 偏った
• 薄い
• 太い

これについては、 こちら 、 こちら 、 こちらをご覧ください 。

ほとんどのオブジェクト（同期された）は1つのスレッドで最大1つブロックされるため、そのようなオブジェクトはこのスレッドにバイアスをかけることができ、ストリーム内のこのオブジェクトの同期操作の価格は大幅に削減されます。 別のスレッドがバイアスされたオブジェクトにアクセスしようとすると、このオブジェクトのロックはシンロックに切り替わります。

切り替え自体は比較的高価であるため、JVMの開始時に遅延があります。デフォルトでは、すべてのロックがシンとして作成され、競合が検出されず、同じスレッドでコードが使用される場合、遅延が終了するとそのようなロックがバイアスされます。 つまり、JVMはロックの使用シナリオを最初から定義しようとするため、使用するスイッチの数が少なくなります。 したがって、BiasedLockingStartupDelayをゼロに設定すると、同期コードの主要部分が同じストリームでのみ使用されると予想されます。

-XX：+ OptimizeStringConcat

また、非常に興味深いオプションです。 似ているパターンを認識する

 StringBuilder().append(...).toString() //   StringBuilder().append(new StringBuiler().append(...).toString()).toString() 

また、新しい連結操作のためにメモリを絶えず割り当てる代わりに、各連結オブジェクトの文字の総数を計算して、メモリを1回だけ割り当てようとします。
つまり、20文字の文字列に対してappend（）操作を20回呼び出すと、 char配列の作成は、400文字の長さで1回発生します。

XX：+ OptimizeFill

配列の充填/コピーサイクルは、作業を高速化するための直接的な機械命令に置き換えられます。
たとえば、次のブロック（Arrays.fill（）から取得）：

  for (int i=fromIndex; i<toIndex; i++) a[i] = val; 

memsetに似た対応するプロセッサ命令で完全に置き換えられますが、memcpyは下位レベルのもののみです。

XX：+ EliminateAutoBox

名前に基づいて、フラグは何らかの方法でオートボクシング操作の数を減らす必要があります。 残念ながら、私はまだこのフラグが何をしているのか理解できませんでした。 これが整数シェルにのみ適用されることを明確にすることができた唯一のもの。

-XX：+ UseCompressedStrings

私の意見では、かなり議論の余地のあるオプションです...遠くの90年代に、Java開発者が文字ごとに2バイトを節約しなかった場合、今日このような最適化はかなりばかげて見えます。 誰かが推測しなかった場合、このオプションは文字配列を可能な限り文字列（ASCII）のバイト配列に置き換えます。 本質的に：

 char[] -> byte[] 

したがって、メモリを大幅に節約できます。 しかし、型が変化しているという事実を考慮すると、特定の操作中の型制御のオーバーヘッドが現れます。 つまり、このオプションを使用すると、JVMのパフォーマンスが低下する可能性があります。 実際、オプションがデフォルトで無効になっているのはそのためです。

-XX：+ UseStringCache

名前から判断すると、かなり不思議なオプションであり、何らかの方法で行をキャッシュする必要があります。 どうやって？ 明確ではありません。 情報はありません。 はい、 コードは何もしていないようです。 誰かが明確にできたら嬉しいです。

-XX：+ UseCompressedOops

まず、いくつかの事実：

• 32ビットJVMのオブジェクトへのポインターのサイズは32ビットです。 64ビット-64ビット。 したがって、最初のケースでは、サイズが2 ^ 32バイト（4 GB）のアドレススペースを使用でき、2番目のケースでは、2 ^ 64バイトを使用できます。
• Javaのオブジェクトのサイズは、仮想マシンのサイズに関係なく、8バイトの倍数です（これはすべての仮想マシンに当てはまるわけではありませんが、ホットスポットに関するものです）。 つまり、32ビットポインターを使用する場合、最後の3ビットは常にゼロになります。実際、仮想マシンは実際には29ビットしか使用しません。

このオプションにより、64ビットJVMのポインターのサイズを32ビットに減らすことができますが、この場合、ヒープサイズは4 GBに制限されているため、短縮ポインターに加えて、8バイトの多重度のプロパティが使用されます。 その結果、サイズ2 ^ 35バイト（32 GB）のアドレス空間を32ビットのポインターで使用する機会が得られます。
実際、仮想マシン内には、メモリ内の特定のバイトではなく、オブジェクトへのポインターがあります。 このような仮定（多重度について）により、ポインターの変換に追加のコストが発生することは明らかです。 しかし、本質的にこれは1つのシフトと合計の操作です。

ポインター自体のサイズを小さくすることに加えて、このオプションはオブジェクトのヘッダーと作成されたオブジェクト内のすべての種類のアライメントとシフトも削減します。これにより、アプリケーションモデルに応じて平均メモリ消費を20〜60％削減できます。

つまり、欠点は次のとおりです。

• 最大ヒープサイズは32 GB（16バイトのオブジェクト多重度を持つJRockitの場合は64 GB）に制限されています。
• 余分に表示されます。 JVMリンクをネイティブに、またはその逆に変換するコスト。

このオプションにはほとんどのアプリケーションでいくつかの利点があるため、JDK 6 update 23以降では、JDK 7と同様にデフォルトで有効になっています。詳細はこちらとこちら 。

-XX：+ EliminateLocks

ロックを組み合わせて不要なロックを排除するオプション。 たとえば、次のブロック：

 synchronized (object) { //doSomething1 } synchronized (object) { //doSomething2 } 

 synchronized (object) { //doSomething3 } //doSomething4 synchronized (object) { //doSomething5 } 

それに応じて変換されます

 synchronized (object) { //doSomething1 //doSomething2 } 

 synchronized (object) { //doSomething3 //doSomething4 //doSomething5 } 

これにより、モニターのキャプチャー試行回数が削減されます。

おわりに

1つの記事に700個までのフラグをすべて入れるのは非常に難しいため、かなり多くの興味深いオプションが船外に残っています。 コレクターを調整するためのオプションには特に触れなかったので、これはかなり広範で複雑なトピックであり、いくつかの投稿に値します。 この記事がお役に立てば幸いです。