“What the JIT!? Anatomy of the OpenJDK HotSpot VM”という記事で触れたとおり、HotSpotの実行エンジンはJust-in-Time (JIT)を持っている。起動時間を改善するために、階層化されたコンパイルがコードの解釈時に開始され、メソッドがクライアントコンパイルレベル(異なるプロファイル情報が存在する場合は除く)でコンパイルされる第1,第2層もしくは第3層に素早く移行し、最終的にサーバコンパイルレベルに移行する(これに関するより詳しい情報は上記の記事を参照)。しかし、コンパイルレベルの改善を行なった後でもHotSpotは未だにバイトコードを解釈し始め、それからJIT動作に移行する。
今年の9月に、HotSpotにAhead-of-Time (AOT)コンパイル(訳注:事前コンパイル)機能を加えるための提案が提出された。AOTはプリコンパイルされたクラスをロードすることにより起動時間を改善し、解釈モードや低い最適化コンパイルレベルでそれらのクラスを実行しないように支援する。
AOTコンパイルは動的コンパイラにとっては新しいことではない。IBMのJ9 VMはAOTをサポートしており、Excelsior JETや他のコンパイラも行なっている。AOTは多くの動的コンパイラの起動/ウォームアップ時間を短縮することを支援している。これは既にネイティブコードのにコンパイルされた(共有)ライブラリを用いることで実現されている。
JITコンパイラと同様、JEPで提案されているAOTコンパイルは階層モードと非階層モードを持つだろう。違いはプロファイル情報の収集とJITリコンパイルにある。記事で言及したように、階層コンパイルでは第2層で単純なプロファイル情報を収集する。階層化AOTコンパイルされたコードでも同様の処理が行われる。そして、AOT起動のしきい値に達したとき、それらのメソッドは第3層でクライアントコンパイラによりリコンパイルされ、第4層で行われるサーバリコンパイルを行うための完全なプロファイル情報が収集可能となる。
この提案はHotSpotコンパイラチームのリードであるVladimir Kozlov氏によって行われ、最初のリリースではjava.baseモジュールだけが階層化AOTとしてサポートされると言及された。このベースモジュールはよく知られており、内部テストを通じて役立つというのがこの理由である。
AOTはGraalをコードを生成するためのバックエンドとして用いた‘jaotc'と呼ばれるツールを提供する。Graal動的コンパイラはHotSpot VMと統合され、JVMコンパイラインタフェース(JVMCI)に依存している。そのため、(GraalもしくはAOTをサポートする)JDKはJVMCIもサポートしなければならない。Oracle technetworkサイトでJVMCIビルドを有効にしたいくつかのビルドが入手可能である。
提案によれば、jaotcツールは様々なフラグをサポートしている。
--module <name> コンパイルする
--output <file> 出力ファイル名
--compile-commands <file> コンパイルコマンドのファイル名
--compile-for-tiered 階層化コンパイルのための生成されたプロファイルコード
--classpath <path> ユーザのクラスファイルの場所指定
--threads <number> コンパイルに使用するスレッドの数
--ignore-errors クラスロードの間に送出された全ての例外を無視する
--exit-on-error コンパイルエラー時にexitする
--info コンパイルの間の情報を表示する
--verbose 冗長な情報を表示する
--debug デバッグ情報を表示する
--help Print this usage message この使用方法に関するメッセージを表示する
--version バージョン情報
-J<flag> ランタイムシステムに<flag> を直接渡す
また、JVM製品は以下のフラグをサポートするだろう。
+/-UseAOT - AOTコンパイルされたファイルを使用する
+/-PrintAOT - 使用されたAOTクラスとメソッドを表示する
AOTLibrary=<file> - AOTライブラリファイルを指定する
ユーザが使用可能となる予定の、製品向けではない開発用フラグもいくつか存在する。
PrintAOTStatistics - AOT統計を表示する
UseAOTStrictLoading - AOTライブラリのいずれかが不正な設定の場合にVMをexitする
この提案ではAOTの実行時イベントが統一GCログと統合され、下記のタグがサポートされる予定であることも述べられている。
aotclassfingerprint
aotclassload
aotclassresolve
他の提案と同様にリスクの列挙と行われた仮定が存在し、AOTの提案によるリスクは下記のように強調されている。
プリコンパイルコードの利用により最適より劣るコードが使用され、性能の損失を引き起こす可能性があります。性能テストにより、いくつかのアプリケーションでAOTコンパイルのコードの利点があることがわかった一方で、他のものでは明確に悪化したものもありました。AOT機能は場合により有効にするオプションであるため、ユーザアプリケーションでの性能劣化は回避可能です。もしユーザがアプリケーションの起動が遅くなったことや、期待したピーク性能に達していないことに気づいたら、AOTライブラリなしで新しいJDKをリビルドするだけでよいのです。
Rate this Article
- Editor Review
- Chief Editor Action