（アプリのパフォーマンスの点で）JITコンパイラでAOTコンパイラを打ち負かすのはなぜ難しいのですか？
JITの固有の利点（実行時にのみ利用可能な情報を使用できる）により、コンパイルされたコードのパフォーマンスの点で、JITコンパイラーは最終的にAOTコンパイラーよりも優れていると考えていました。 1つの議論は、AOTコンパイラーはコードのコンパイルにより多くの時間を費やすことができるが、サーバーVMも多くの時間を費やす可能性があるということです。
JITがAOTコンパイラを打ち負かす場合があることは理解していますが、それでもほとんどの場合、遅れているようです。
だから私の質問は、JITコンパイラがAOTコンパイラを打ち負かすのを妨げている特定の難しい問題は何ですか？
編集：
いくつかの一般的な議論：
- AOTコンパイラーは、高度な最適化を行うためにより多くの時間を費やすことができます->サーバーを数日間実行している場合VMそれ以上ではないにしても、同じ時間を費やします。
- バイトコードの解釈にはコストがかかります->最近のほとんどのJITコンパイラはネイティブマシン命令をキャッシュします。
さらに別の編集：
具体的な例については、次の記事を参照してください： スイングパフォーマンスの向上：JITとAOTのコンパイル 。この記事から私が収集できることから、著者は基本的に、ホットスポットがない場合、ランタイム情報を持つことの利点が減少し、したがってJITのオーバーヘッドなしでAOTが勝つと言っています。でも40％？それはあまり意味がないようです。比較されたJITコンパイラがこの状況に合わせて調整されていなかったというだけですか？それとももっと根本的なものですか？
JITとAOT（事前）コンパイルの間には明確なトレードオフがあります。
あなたが述べたように、JITは最適化に役立つ実行時情報にアクセスできます。これには、実行しているマシンに関するデータが含まれ、プラットフォーム固有のネイティブ最適化が可能になります。ただし、JITには、バイトコードをネイティブ命令に変換するオーバーヘッドもあります。
このオーバーヘッドは、高速起動またはほぼリアルタイムの応答が必要なアプリケーションで明らかになることがよくあります。マシンに高度な最適化のための十分なリソースがない場合、またはコードの性質が「積極的に最適化」できないような場合にも、JITはそれほど効果的ではありません。
たとえば、 リンクした記事 から取得：
...明確なパフォーマンスのボトルネックがない場合、何を改善する必要がありますか？ご想像のとおり、プロファイルガイド付きJITコンパイラにも同じ問題があります。積極的に最適化するためのいくつかのホットスポットの代わりに、そのまま残された「ウォームスポット」がたくさんあります。
AOTコンパイラーは、最適化に好きなだけ時間を費やすことができますが、JITコンパイルは、時間要件（応答性を維持するため）とクライアントマシンのリソースによって制限されます。このため、AOTコンパイラーは、JIT中にコストがかかりすぎる複雑な最適化を実行できます。
こちらもご覧くださいSO質問： JITコンパイラとオフラインコンパイラ