JVMがJITコンパイル済みコードをキャッシュしないのはなぜですか？

Sunの標準的なJVM実装は、かなり洗練された最適化をバイトコードに適用して、コードが数回実行された後、ネイティブに近い実行速度を取得します。

問題は、このコンパイルされたコードが、同じ関数/クラスの後続の使用中に使用するためにディスクにキャッシュされないのはなぜですか？

現状では、プログラムが実行されるたびに、JITコンパイラは、コンパイル済みのバージョンのコードを使用するのではなく、新たに起動します。この機能を追加すると、バイトコードが本質的に解釈されているときに、プログラムの最初の実行時間が大幅に増加しませんか？

@MYYNが投稿したリンクのカットアンドペーストに頼らずに、これは、JVMが実行する最適化が静的ではなく動的であり、データパターンとコードパターンに基づいているためと考えられます。これらのデータパターンはアプリケーションの存続期間中に変更され、キャッシュされた最適化が最適ではなくなる可能性があります。

したがって、保存された最適化がまだ最適であるかどうかを確認するメカニズムが必要です。

OracleのJVMは確かにそのように文書化されています-Oracleを引用すると、

コンパイラーは、Oracle JVMのクラス解決モデルを利用して、データベースの呼び出し、セッション、またはインスタンス全体でコンパイルされたJavaメソッドをオプションで永続化できます。このような永続性により、セマンティックにJavaコードが変更されていないことがわかっている場合、セッションまたはインスタンス間での不要な再コンパイルのオーバーヘッドが回避されます。

すべての洗練されたVM実装が同様のオプションを提供しない理由はわかりません。

既存の回答の更新-Java 8には、これを解決するためのJEPがあります。

=> JEP 145：コンパイルされたコードのキャッシュ。新しいリンク。

非常に高いレベルで、その明記された目標は次のとおりです。

大規模なJavaアプリケーションの起動時間を改善するために、以前の実行からコンパイルされたネイティブコードを保存して再利用します。

お役に立てれば。

Excelsior JETには、2001年にリリースされたバージョン2.0以降のキャッシュJITコンパイラがあります。さらに、そのAOTコンパイラは、すべての最適化を使用して、キャッシュを単一のDLL /共有オブジェクトに再コンパイルする場合があります。

JVMの実装に関与していない実際の理由はわかりませんが、もっともらしい理由はいくつか考えられます。

• Javaのアイデアは、一度だけ実行される任意の場所の言語であり、クラスファイルにプリコンパイルされたものを入れることは一種の違反です（もちろん、実際のバイトコードはまだ存在するため、「一種」のみ）
• 特に、同じプログラムを複数の異なるJVMで実行した場合は、クラスファイルのサイズが大きくなります（異なるバージョンを異なるJVMであると考える場合、これは実際には珍しくありません）。本当にしなければならない）
• クラスファイル自体は書き込み可能でない可能性があります（それを確認するのはかなり簡単ですが）
• JVM最適化は実行時情報に部分的に基づいており、他の実行ではそれらは適切でない可能性があります（ただし、いくつかの利点は提供されるはずです）

しかし、私は本当に推測しており、ご覧のとおり、私の理由のいずれかが実際のショーストッパーであるとはあまり考えていません。私はSunがこのサポートを優先事項と見なしていないと考えています。おそらく私の最初の理由は真実に近いでしょう。これを習慣的に行うと、Javaクラスファイルが実際にはVMごとに個別のバージョンを必要とするのではなく、クロスプラットフォーム。

私の優先する方法は、実際に前もって明示的にこのようなことを行うために使用できる個別のバイトコードからネイティブへのトランスレータを持ち、特定のVM用に明示的に構築されたクラスファイルを作成することです。異なるVMでも実行できます。しかし、それはおそらく私の経験によるものです。私はほとんどJava MEを行ってきましたが、Javaコンパイラーがコンパイルに関して賢くないのは本当に痛いです。