🛃 📷 🕵🏼 Java HotSpot JITコンパイラ-デバイス、監視、およびチューニング（パート1） 😞 👨🏽‍🚀 📟

JIT（Just-in-Time）コンパイラは、アプリケーションのパフォーマンスに大きな影響を与えます。それがどのように機能するか、それを監視および構成する方法を理解することは、すべてのJavaプログラマーにとって重要です。この2部構成の記事シリーズでは、HotSpot JVMのJITコンパイラ、その動作を監視する方法、およびその構成方法について説明します。この最初の部分では、JITコンパイラがどのように機能し、どのように監視できるかを見ていきます。

AOTおよびJITコンパイラ

プロセッサは、限られた一連の命令（マシンコード）のみを実行できます。プログラムをプロセッサで実行するには、プログラムをマシンコードとして表す必要があります。

CやC ++などのコンパイルされたプログラミング言語があります。これらの言語で書かれたプログラムは、マシンコードとして配布されます。プログラムが作成された後、特別なプロセスであるAhead-of-Time（AOT）コンパイラー（通常は単にコンパイラーと呼ばれます）が、ソースコードをマシンコードに変換します。マシンコードは、特定のプロセッサモデルで実行するように設計されています。共通のアーキテクチャを持つプロセッサは、同じコードを実行できます。後のプロセッサモデルは通常、前のモデルの命令をサポートしますが、その逆はサポートしません。たとえば、Intel Sandy Bridgeプロセッサ用のAVX命令を使用するマシンコードは、古いIntelプロセッサでは実行できません。この問題を解決するには、さまざまな方法があります。たとえば、プログラムの重要な部分を、メインプロセッサモデルのバージョンがあるライブラリに転送します。しかし、多くの場合、プログラムは比較的古いプロセッサモデル用にコンパイルされており、新しい命令セットを利用していません。

コンパイルされたプログラミング言語とは対照的に、PerlやPHPなどの解釈された言語があります。このアプローチでは、インタープリターが存在する任意のプラットフォームで同じソースコードを実行できます。このアプローチの欠点は、解釈されたコードが同じことを行うマシンコードよりも遅いことです。

Java言語は、コンパイルされた言語と解釈された言語の間のクロスという、異なるアプローチを提供します。Javaアプリケーションは、中間の低レベルコードであるバイトコードにコンパイルされます。

各操作のエンコードに正確に1バイトが使用されるため、バイトコードという名前が選択されました。Java10には約200の操作があります。

次に、バイトコードは、JVMおよび解釈された言語プログラムによって実行されます。ただし、バイトコードの形式は明確に定義されているため、JVMは実行時にそれをマシンコードにコンパイルできます。当然、古いバージョンのJVMは、その後の新しいプロセッサ命令セットを使用してマシンコードを生成することはできません。一方、Javaプログラムを高速化するために、再コンパイルする必要はありません。新しいJVMで実行するだけで十分です。

HotSpotJITコンパイラ

さまざまなJVMJIT実装は、さまざまな方法でコンパイラを実装できます。この記事では、Oracle HotSpotJVMとそのJITコンパイラの実装について説明します。 HotSpotという名前は、JVMがバイトコードをコンパイルするために使用するアプローチに由来しています。通常、アプリケーションでは、コードのごく一部のみが非常に頻繁に実行され、アプリケーションのパフォーマンスは主にこれらの特定の部分の実行速度に依存します。コードのこれらの部分はホットスポットと呼ばれ、JITコンパイラがコンパイルするものです。このアプローチの根底にはいくつかの判断があります。コードが1回だけ実行される場合、そのコードのコンパイルは時間の無駄です。もう1つの理由は最適化です。 JVMがコードを実行する回数が多いほど、JVMが蓄積する統計が多くなり、それを使用して、より最適化されたコードを生成できます。さらに、コンパイラは仮想マシンのリソースをアプリケーション自体と共有するため、プロファイリングと最適化に費やされたリソースを使用してアプリケーション自体を実行できます。これにより、一定のバランスが守られます。 HotSpotコンパイラの作業単位は、メソッドとループです。

コンパイルされたコードの単位はnmethod（ネイティブメソッドの略）と呼ばれます。

階層型コンパイル

実際、HotSpot JVMには1つではなく、C1とC2の2つのコンパイラがあります。他の名前はクライアントとサーバーです。歴史的に、C1はGUIアプリケーションで使用され、C2はサーバーアプリケーションで使用されていました。コンパイラは、コードのコンパイルを開始する速度が異なります。C1はコードのコンパイルを高速化し始めますが、C2はより最適化されたコードを生成できます。

以前のバージョンのJVMでは、クライアントの-clientフラグと -serverまたは-d64を使用してコンパイラを選択する必要があり ました。サーバールーム用。JDK 6では、マルチレベルコンパイルモードが導入されました。大まかに言えば、その本質は、解釈されたコードからコンパイラC1、次にC2によって生成されたコードへの順次遷移にあります。JDK 8では、-client、-server、および-d64フラグは無視され、JDK 11では、-d64フラグが削除され、エラーが発生します。-XX：-TieredCompilationフラグを使用して、階層型コンパイルモードをオフにできます。

5つのコンパイルレベルがあります。

0-解釈されたコード
1-C1は完全に最適化されています（プロファイリングなし）
2-メソッド呼び出しとループ反復の数を考慮したC1-
3-プロファイリングを使用したC1-
4-C2

レベル間の遷移の典型的なシーケンスを表に示します。

シーケンス	説明
0-3-4	通訳、レベル3、レベル4。最も一般的。
0-2-3-4	, 4 (C2) . 2. , 3 , , 4.
0-2-4	, 3 . 4 3. 2 4.
0-3-1	. 3, , 4 . 1.
0-4	.

Code cache

JITコンパイラによってコンパイルされたマシンコードは、コードキャッシュと呼ばれるメモリ領域に格納されます。また、インタープリターコードなど、仮想マシン自体のマシンコードも格納されます。このメモリ領域のサイズは制限されており、いっぱいになるとコンパイルが停止します。この場合、一部の「ホット」メソッドは引き続きインタープリターによって実行されます。オーバーフローが発生した場合、JVMは次のメッセージを表示します。

Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full.
         Compiler has been disabled.

このメモリ領域のオーバーフローを見つける別の方法は、コンパイラ操作のロギングを有効にすることです（これを行う方法については以下で説明します）。

コードキャッシュは、JVMの他のメモリ領域と同じ方法で構成できます。初期サイズは、-XX：InitialCodeCacheSizeパラメーターで指定されます。最大サイズは、-XX：ReservedCodeCacheSizeパラメーターで指定されます。デフォルトでは、初期サイズは2496KBです。最大サイズは、階層型コンパイルがオフの場合は48 MB、オンの場合は240MBです。

Java 9以降、コードキャッシュは3つのセグメントに分割されています（合計サイズは上記の制限によって制限されています）。

JVM internal (non-method code). , JVM, , . . 5.5 MB. -XX:NonNMethodCodeHeapSize.
Profiled code. . non-method code . 21.2 MB 117.2 MB . -XX:ProfiledCodeHeapSize.
Non-profiled code. . non-method code . 21.2 MB 117.2 MB . -XX: NonProfiledCodeHeapSize.

-XX：+ PrintCompilationフラグを使用してコンパイルプロセスのログを有効にできます（デフォルトでは無効になっています）。このフラグが設定されている場合、JVMは、メソッドまたはループがコンパイルされるたびに、標準出力（STDOUT）にメッセージを書き込みます。ほとんどのメッセージの形式は次のとおりです。timestampcompilation_id属性tiered_levelmethod_name sizedeopt。

タイムスタンプフィールドは、JVMの開始からの時間です。

compile_idフィールドは、問題の内部IDです。通常、メッセージごとに順番に大きくなりますが、順序が狂っている場合もあります。これは、複数のコンパイルスレッドが並行して実行されている場合に発生する可能性があります。

属性フィールドは、コンパイルされたコードに関する追加情報を運ぶ5文字のセットです。いずれかの属性が該当しない場合は、代わりにスペースが表示されます。次の属性が存在します。

％-OSR（オンスタック置換）;
s-メソッドは同期されます。
！-メソッドには例外ハンドラーが含まれています。
b-コンパイルはブロッキングモードで発生しました。
n-コンパイルされたメソッドは、ネイティブメソッドのラッパーです。

OSRはオンスタック置換の略です。コンパイルは非同期プロセスです。メソッドをコンパイルする必要があるとJVMが判断すると、そのメソッドはキューに入れられます。メソッドがコンパイルされている間、JVMはインタープリターによってメソッドを実行し続けます。次回メソッドが再度呼び出されると、コンパイルされたバージョンが実行されます。長いサイクルの場合、メソッドの完了を待つことは実用的ではありません-それはまったく完了しないかもしれません。 JVMはループの本体をコンパイルし、コンパイルされたバージョンの実行を開始する必要があります。 JVMは、スレッドの状態をスタックに格納します。呼び出されたメソッドごとに、新しいStack Frameオブジェクトがスタック上に作成され、メソッドパラメータ、ローカル変数、戻り値、およびその他の値が格納されます。 OSR中に、前のスタックフレームを置き換えるために新しいスタックフレームが作成されます。

出典： Java HotSpotTM仮想マシンクライアントコンパイラ：テクノロジとアプリケーション

「s」および「！」属性説明は必要ないと思います。

「b」属性は、コンパイルがバックグラウンドで行われなかったことを意味し、最新バージョンのJVMでは検出されないはずです。

「n」属性は、コンパイルされたメソッドがネイティブメソッドのラッパーであることを意味します。

tiered_levelフィールドには、コードがコンパイルされたレベル番号が含まれます。階層化されたコンパイルが無効になっている場合は空にすることができます。

method_nameフィールドには、コンパイルされたメソッドの名前またはコンパイルされたループを含むメソッドの名前が含まれます。

サイズフィールドには、結果のマシンコードのサイズではなく、コンパイルされたバイトコードのサイズが含まれます。サイズはバイト単位です。

deoptフィールドはすべてのメッセージに表示されるわけではなく、実行された最適化解除の名前が含まれ、「madenotentrant」や「madezombie」などのメッセージが含まれる場合があります。

次のエントリがログに表示される場合があります。timestampcompile_idCOMPILESKIPPED：reason。これは、メソッドのコンパイル時に問題が発生したことを意味します。これが予想される場合があります。

コードキャッシュがいっぱいです-コードキャッシュメモリ領域のサイズを増やす必要があります。
同時クラスローディング-クラスはコンパイル時に変更されました。

コードキャッシュのオーバーフローを除いて、すべての場合で、JVMは再コンパイルを試みます。そうでない場合は、コードを単純化してみてください。

プロセスが-XX：+ PrintCompilationフラグなしで開始された場合、jstatユーティリティを使用してコンパイルプロセスを確認できます。 Jstatには、コンパイル情報を表示するための2つのオプションがあります。 -compiler

パラメーターは、コンパイラー操作の要約を表示します（5003はプロセスIDです）。

% jstat -compiler 5003
Compiled Failed Invalid   Time   FailedType FailedMethod
     206         0          0    1.97                0

このコマンドは、コンパイルに失敗したメソッドの数と最後のそのようなメソッドの名前も表示します。 -printcompilation

パラメーターは、最後にコンパイルされたメソッドに関する情報を出力します。2番目のパラメーターである操作の繰り返し期間と組み合わせると、コンパイルプロセスを経時的に観察できます。次の例では、-printcompilationコマンドを毎秒（1000ms）実行します。

% jstat -printcompilation 5003 1000
Compiled  Size  Type Method
     207     64    1 java/lang/CharacterDataLatin1 toUpperCase
     208      5    1 java/math/BigDecimal$StringBuilderHelper getCharArray

第二部の計画

次のパートでは、JVMがコンパイルを開始するカウンターのしきい値と、それらを変更する方法について説明します。また、JVMがコンパイラスレッドの数を選択する方法、変更する方法、およびいつ実行する必要があるかについても説明します。最後に、JITコンパイラによって実行される最適化のいくつかを簡単に見てみましょう。

参考文献とリンク

Javaのパフォーマンス：Java 8、11、およびそれ以降のチューニングとプログラミングに関する詳細なアドバイス、Scott Oaks ISBN：978-1-492-05611-9。
Javaの最適化：JVMアプリケーションのパフォーマンスを改善するための実用的な手法、Benjamin J. Evans、James Gough、およびChrisNewland。ISBN：978-1-492-02579-5。
JEP 197：セグメント化されたコードキャッシュ
Java HotSpotTM仮想マシンクライアントコンパイラ：テクノロジとアプリケーション

Java HotSpot JITコンパイラ-デバイス、監視、およびチューニング（パート1）