この記事では、さまざまなJITコンパイラの実装の詳細と操作、および最適化戦略について説明します。十分に詳細に説明しますが、多くの重要な概念は省略します。つまり、この記事には、実装と言語の比較で合理的な結論に達するのに十分な情報がありません。

JITコンパイラの基本を理解するには、この記事をお読みください。

小さなメモ：

, , , - . , JIT ( ), , . , , , , . - , , .

Pypy
GraalVM C
OSR
JIT

()

LuaJITはいわゆるトレースを使用します。 Pypyはメタトレースを実行します。つまり、システムを使用してトレースおよびJITインタープリターを生成します。 PypyとLuaJITは、模範的なPythonとLuaの実装ではなく、スタンドアロンのプロジェクトです。私はLuaJITを驚くほど高速であると特徴づけ、それ自体を最速の動的言語実装の1つとして説明します-そして私は絶対にそれを信じています。

トレースを開始するタイミングを理解するために、インタープリターループはホットループを探します（ホットコードの概念はすべてのJITコンパイラーに共通です！）。次に、コンパイラはループを「トレース」し、実行可能な操作を記録して、適切に最適化されたマシンコードをコンパイルします。 LuaJITでは、コンパイルは、LuaJITに固有の命令のような中間表現を持つトレースに基づいています。

Pypyでトレースを実装する方法

Pypyは、1619回の実行後に関数のトレースを開始し、1039回の実行後にコンパイルします。つまり、関数がより高速に動作を開始するには、関数の約3000回の実行が必要です。これらの値はPypyチームによって慎重に選択されており、一般にコンパイラの世界では、多くの定数が慎重に選択されています。

動的言語は最適化を困難にします。以下のコードFalseは、常にfalseになるため、より厳密な言語で静的に削除できます。ただし、Python 2では、これは実行時まで保証できません。

if False:
  print("FALSE")

インテリジェントプログラムの場合、この条件は常にfalseになります。残念ながら、値Falseは再定義でき、式はループになり、別の場所で再定義できます。したがって、Pypyは「ガード」を作成できます。ディフェンダーが失敗した場合、JITは解釈ループにフォールバックします。Pypyはその後と呼ばれる別の定数（200）を使用してトレース意欲をループの終了前に新しいパスの残りの部分をコンパイルするかどうかを決定します。このサブパスはブリッジと呼ばれます。

さらに、Pypyはこれらの定数を引数として提供します。これらの定数は、実行時にカスタマイズして、構成の展開、つまりループ拡張やインライン化を行うことができます。さらに、コンパイルが完了した後に表示できるフックを提供します。

def print_compiler_info(i):
  print(i.type)
pypyjit.set_compile_hook(print_compiler_info)

for i in range(10000):
  if False:
    pass

print(pypyjit.get_stats_snapshot().counters)

上記では、適用されたコンパイルのタイプを表示するためのコンパイルフックを備えた純粋なPythonプログラムを作成しました。このコードは、最後に防御側の数を示すデータも出力します。このプログラムでは、1つのループコンパイルと66のディフェンダーを取得しました。式をif単純なアウトオブループパスに置き換えたところ、for残りのディフェンダーは59人だけでした。

for i in range(10000):
  pass # removing the `if False` saved 7 guards!

これらの2行をループforに追加することで、2つのコンパイルが得られ、そのうちの1つは「ブリッジ」タイプでした。

if random.randint(1, 100) < 20:
  False = True

待って、あなたはメタトレースについて話していました！

メタトレースの背後にある考え方は、「インタープリターを作成してコンパイラーを無料で入手する」または「インタープリターをJITコンパイラーに変える」と説明できます。コンパイラーを書くのは難しいです、そしてあなたがそれを無料で手に入れることができれば、アイデアはクールです。 Pypyには、インタープリターとコンパイラーが「含まれています」が、従来のコンパイラーを明示的に実装していません。

PypyにはRPythonツール（Pypy用に構築）があります。通訳を書くためのフレームワークです。その言語は一種のPythonであり、静的に型付けされています。通訳を書く必要があるのはこの言語です。この言語は、標準のライブラリまたはパッケージが含まれていないため、型付きPythonプログラミング用に設計されていません。 RPythonプログラムはすべて有効なPythonプログラムです。 RPythonコードはCに変換されてから、コンパイルされます。したがって、この言語のメタコンパイラは、コンパイルされたCプログラムとして存在します。

metatraceのプレフィックス「meta」は、プログラムではなく、インタープリターの実行時にトレースが実行されることを意味します。他のインタープリターとほぼ同じように動作しますが、操作を追跡でき、パスを更新することでトレースを最適化するように設計されています。さらにトレースすると、インタープリターパスがより最適化されます。十分に最適化されたインタープリターは、特定のパスに従います。また、RPythonのコンパイルによって取得された、このパスで使用されるマシンコードは、最終的なコンパイルで使用できます。

つまり、Pypyの「コンパイラ」はインタプリタをコンパイルするため、Pypyはメタコンパイラと呼ばれることもあります。最適化されたインタープリターのパスほど、実行しているプログラムをコンパイルしません。

メタトレースの概念は紛らわしいように思われるかもしれません。そのため、説明のために、とだけを理解する非常に貧弱なプログラムを作成a = 0しましたa++to。

# interpreter written with RPython
for line in code:
  if line == "a = 0":
    alloc(a, 0)
  elif line == "a++":
    guard(a, "is_int") # notice how in Python, the type is unknown, but after being interpreted by RPython, the type is known
    guard(a, "> 0")
    int_add(a, 1)

このホットサイクルを実行すると、次のようになります。

a = 0
a++
a++

トラックは次のようになります。

# Trace from numerous logs of the hot loop
a = alloc(0) # guards can go away
a = int_add(a, 1)
a = int_add(a, 2)

# optimize trace to be compiled
a = alloc(2) # the section of code that executes this trace _is_ the compiled code

ただし、コンパイラは特別な個別のモジュールではなく、インタプリタに組み込まれています。したがって、解釈サイクルは次のようになります。

for line in code:
  if traces.is_compiled(line):
    run_compiled(traces.compiled(line))
    continue
  elif traces.is_optimized(line):
    compile(traces.optimized(line))
    continue
  elif line == "a = 0"
  # ....

JVMの概要

私はGraalベースのTruffleRuby言語で4か月間執筆し、それに夢中になりました。

（それがために検索するため、そのように命名ホットスポットホットスポット）は、標準のJavaのインストールに付属している仮想マシンです。マルチレベルコンパイルを実装するためのいくつかのコンパイラが含まれています。Hotspotの250,000行のコードベースはオープンで、3つのガベージコレクターがあります。DevはJITコンパイルに対応します。一部のベンチマークでは、C ++ impls（この場合~~はCPA~~として）よりもうまく機能します。紛争、グーグル）。Hotspotはトレースしませんが、同様のアプローチを使用します。つまり、解釈、プロファイル、およびコンパイルを行います。このアプローチには独自の名前はなく、メソッドベースのJIT（メソッドによる最適化）または階層化されたJITに最も近いものです。

Hotspotで使用される戦略は、後続のJITコンパイラ、言語仮想マシンフレームワーク、特にJavascriptエンジンの多くの作成者に影響を与えました。 Hotspotは、Scala、Kotlin、JRuby、JythonなどのJVM言語の波も生み出しました。 JRubyとJythonは、ソースコードをJVMバイトコードにコンパイルし、Hotspotが実行するRubyとPythonの楽しい実装です。これらのプロジェクトはすべて、Pypyの場合のように、すべてのツールを実装しなくても、PythonおよびRuby言語（PythonよりもRuby）を高速化することに比較的成功しています。ホットスポットは、動的性の低い言語用のJITであるという点でもユニークです（ただし、技術的にはJavaではなくJVMバイトコード用のJITです）。

GraalVMは、Javaコードを備えたJavaVMです。任意のJVM言語（Java、Scala、Kotlinなど）を実行できます。また、SubstrateVMを介してAOTでコンパイルされたコードを操作するためのNativeImageもサポートしています。 TwitterのScalaサービスのかなりの部分がGraalで実行されています。これは、仮想マシンの品質について語っています。Javaで記述されていますが、ある意味ではJVMよりも優れています。

そして、それだけではありません！ GraalVMはTruffleも提供します：AST（抽象構文ツリー）インタープリターを作成することによって言語を実装するためのフレームワーク。通常のJVM言語のようにJVMバイトコードが生成される場合、Truffleには明示的な手順はありません。むしろ、Truffleは単にインタープリターを使用し、Graalと通信して、プロファイリングといわゆる部分スコアリングを使用してマシンコードを直接生成します。部分的な評価は、一言で言えば、この記事の範囲を超えています。このメソッドは、「インタープリターを作成し、コンパイラーを無料で入手してください！」というメタトラッキングの哲学に準拠していますが、アプローチが異なります。

TruffleJS — Truffle- Javascript, V8 , , V8 , Google , . TruffleJS «» V8 ( JS-) , Graal.

JIT-

C

JIT実装では、C拡張機能のサポートに問題が発生することがよくあります。 Lua、Python、Ruby、PHPなどの標準インタープリターにはC APIがあり、ユーザーはその言語でパッケージを作成できるため、実行が大幅に高速化されます。多くのパッケージはCで記述されていますrand。たとえば、numpyのような標準のライブラリ関数です。これらのC拡張機能はすべて、解釈された言語を高速にするために重要です。

C拡張機能は、いくつかの理由で保守が困難です。最も明白な理由は、APIが内部実装を念頭に置いて設計されていることです。さらに、インタープリターがCで記述されていると、C拡張機能の保守が容易になるため、JRubyはC拡張機能をサポートできませんが、Java拡張機能用のAPIはあります。 Pypyは最近、C拡張機能のサポートのベータ版をリリースしましたが、Hyrumの法則のために機能するかどうかはわかりません。 LuaJITは、C拡張機能の追加機能を含むC拡張機能をサポートしています（LuaJITは素晴らしいです！）

Graalは、GraalVMでLLVMバイトコードを実行してTruffleに変換するエンジンであるSulongを使用してこの問題を解決します。 LLVMはツールボックスであり、CをLLVMバイトコードにコンパイルできることを知っておく必要があります（JuliaにはLLVMバックエンドもあります！）。奇妙なことですが、解決策は、40年以上の歴史を持つ優れたコンパイル済み言語を使用して、それを解釈することです。もちろん、適切にコンパイルされたCほど高速には実行されませんが、いくつかの利点があります。

LLVMバイトコードはすでに非常に低レベルです。つまり、Cに関してこの中間表現にJITを適用することは非効率的ではありません。一部のコストは、バイトコードを残りのRubyプログラムと一緒に最適化できるという事実によって補われますが、コンパイルされたCプログラムを最適化することはできません。 ..。これらのメモリストリップ、インライン化、デッドコードストリップなどはすべて、RubyコードからCバイナリを呼び出す代わりに、CおよびRubyコードに適用できます。 TruffleRuby C拡張機能は、いくつかの点でCRubyC拡張機能よりも高速です。

このシステムが機能するためには、Truffleが完全に言語に依存せず、C、Java、またはGraal内の他の言語を切り替えるオーバーヘッドが最小限になることを知っておく必要があります。

GraalがSulongと連携する機能は、言語の高い互換性を可能にする多言語機能の一部です。これはコンパイラにとって良いだけでなく、1つの「アプリケーション」で複数の言語を簡単に使用できることも証明しています。

解釈されたコードに戻ると、より高速です

JITにはインタプリタとコンパイラが含まれており、JITはインタプリタからコンパイラに移動して処理を高速化することを知っています。 Pypyはリターンパスのブリッジを作成しますが、GraalとHotspotの観点からは、これは最適化解除です。完全に異なる概念について話しているわけではありませんが、最適化解除とは、動的言語の必然性に対する解決策ではなく、意識的な最適化としてインタープリターに戻ることを意味します。 HotspotとGraalは、最適化解除、特にGraalを多用します。これは、開発者がコンパイルを厳密に制御でき、最適化のためにコンパイルをさらに制御する必要があるためです（たとえば、Pypyと比較して）。最適化解除はJSエンジンでも使用されますが、ChromeとNode.jsのJavaScriptはそれに依存しているため、これについては後で詳しく説明します。

最適化解除をすばやく適用するには、コンパイラとインタープリターをできるだけ早く切り替えることが重要です。最も単純な実装では、インタープリターは最適化解除を実行するためにコンパイラーに「追いつく」必要があります。追加の複雑さは、非同期ストリームの最適化解除に関連しています。 Graalはフレームのセットを作成し、それを生成されたコードと照合してインタープリターに返します。セーフポイントを使用すると、Javaスレッドを一時停止して、「こんにちは、ガベージコレクター、停止する必要がありますか？」と言うことができます。これにより、スレッド処理に多くのオーバーヘッドが必要なくなります。それはかなり粗雑であることが判明しましたが、最適化解除が適切な戦略となるのに十分な速さで機能します。

Pypyブリッジングの例と同様に、関数のモンキーパッチも最適化解除できます。防御側が失敗したときではなく、ゲリラパッチが適用されたときに最適化解除コードを追加するため、よりエレガントです。

JITの最適化解除の良い例：変換オーバーフローは非公式の用語です。特定のタイプ（たとえばint32）が内部的に表され/割り当てられているが、に変換する必要がある状況について話しint64ます。 TruffleRubyは、V8と同様に、最適化を解除してこれを行います。

たとえば、Rubyvar = 0で質問すると、次のようになりますint32（RubyはそれをFixnumandと呼びBignumますが、表記はint32andを使用しますint64）。で操作を実行するvar、値のオーバーフローが発生するかどうかを確認する必要があります。しかし、チェックすることは1つであり、オーバーフローを処理するコードのコンパイルは、特に数値演算の頻度を考えると、コストがかかります。

コンパイルされた命令を見なくても、この最適化解除によってコードの量がどのように削減されるかがわかります。

int a, b;
int sum = a + b;
if (overflowed) {
  long bigSum = a + b;
  return bigSum;
} else {
  return sum;
}

int a, b;
int sum = a + b;
if (overflowed) {
  Deoptimize!
}

TruffleRubyでは、特定の操作の最初の実行のみが最適化されていないため、操作がオーバーフローするたびにリソースを浪費することはありません。

WETコードは高速コードです。インライン化とOSR

function foo(a, b) {
 return a + b;
}
for (var i = 0; i < 1000000; i++) {
 foo(i, i + 1);
}
foo(1, 2);

これらのトリガーのような些細なことでさえ、V8では最適化されていません！--trace-deoptおよびなどのオプションを使用すると、--trace-optJITに関する多くの情報を収集したり、動作を変更したりできます。 Graalには非常に便利なツールがいくつかありますが、多くの人がインストールしているので、V8を使用します。

最適化解除はfoo(1, 2)、この呼び出しがループ内で行われたため、不可解な最後の行（）から開始されます。「通話に対するタイプのフィードバックが不十分です」というメッセージが表示されます（最適化解除の理由の完全なリストはここにあり、「理由がない」という面白い理由があります）。これにより、リテラル1とを表示する入力フレームが作成されます2。

では、なぜ最適化を解除するのでしょうか。 V8は型キャストを行うためのスマート十分である：それは時にiタイプがありますinteger、リテラルも渡されますinteger。

これを理解するために、最後の行をに置き換えましょうfoo(i, i +1)。ただし、最適化解除は引き続き適用されます。今回のみ、「バイナリ操作のタイプフィードバックが不十分です」というメッセージが異なります。なぜ？！結局のところ、これはループで実行される操作とまったく同じであり、同じ変数を使用します。

答えは、私の友人、オンスタック置換（OSR）にあります。インライン化は強力なコンパイラ最適化（JITだけでなく）であり、関数は関数ではなくなり、コンテンツは呼び出しの場所に渡されます。 JITコンパイラは、実行時にコードを変更することで速度を上げるためにインライン化できます（コンパイルされた言語は静的にインライン化することしかできません）。

// partial output from printing inlining details

[compiling method 0x04a0439f3751 <JSFunction (sfi = 0x4a06ab56121)> using TurboFan OSR]
0x04a06ab561e9 <SharedFunctionInfo foo>: IsInlineable? true
Inlining small function(s) at call site #49:JSCall

したがって、V8はコンパイルされfoo、インラインにできるかどうかを判断し、OSRとインラインになります。ただし、これはホットパスであり、インライン化の時点で最後の行がまだインタープリターにないため、エンジンはループ内のコードに対してのみこれを実行します。したがって、V8はfooループで使用されるのではなく、インラインバージョンで使用されるため、関数のタイプに関する十分なフィードバックがまだありません。適用された場合--no-use-osr、文字通りまたはi。を渡しても、最適化が解除されることはありません。ただし、インライン化しないと、わずか100万回の繰り返しでも実行速度が著しく遅くなります。 JITコンパイラは、ソリューションなし、トレードオフのみの原則を実際に具体化しています。最適化解除には費用がかかりますが、メソッドの検索とインライン化のコストとは比較できません。この場合はこの方法が推奨されます。

裏地は信じられないほど効果的です！上記のコードをいくつかのゼロを追加して実行しましたが、インライン化をオフにすると、実行速度が4倍遅くなりました。

この記事はJITに関するものですが、インライン化はコンパイルされた言語でも効果的です。すべてのLLVM言語は積極的にインライン化を使用します。LLVMもそれを行うためです。ジュリアはLLVMなしでインライン化されていますが、これは彼女の本質です。JITは、ランタイムヒューリスティックを使用してインライン化でき、OSRを使用して非インライン化モードとインライン化モードを切り替えることができます。

JITとLLVMに関する注記

LLVMは、コンパイル関連のツールを多数提供します。 Juliaは、Rust、Swift、Crystalと同様に、LLVMで動作します（これは大きなツールボックスであり、言語ごとに使用方法が異なることに注意してください）。 LLVMには重要な動的JITが組み込まれていませんが、これはJITもサポートする大規模ですばらしいプロジェクトであると言えば十分です。 JavaScriptCoreコンパイルの第4レベルでは、しばらくの間LLVMバックエンドが使用されていましたが、2年以内に置き換えられました。それ以来、このツールキットは、主に動的環境で動作するように設計されていないため、動的JITにはあまり適していません。 Pypyは5〜6回試しましたが、JSCに落ち着きました。 LLVMでは、割り当てのシンクとコードの移動が制限されていました。範囲推論のような強力なJIT機能を使用することも不可能でした（キャストのようなものですが、値の範囲がわかっています）。しかし、さらに重要なのは、LLVMを使用すると、コンパイルに多くのリソースが費やされることです。

命令ベースの中間表現の代わりに、それ自体を変更する大きなグラフがある場合はどうなりますか？

中間表現として、LLVMバイトコードとPython / Ruby / Javaバイトコードについて説明しました。それらはすべて、指示の形である種の言語のように見えます。Hotspot、Graal、およびV8は、低レベルのASTである「Seaof Nodes」中間表現（Hotspotで導入）を使用します。プロファイリングの重要な部分は、めったに使用されない（または、あるパターンの場合は重複する）特定のパスの概念に基づいているため、これは効果的なビューです。これらのASTコンパイラはASTパーサーとは異なることに注意してください。

普段は「家でやってみよう！」という立場を貫いていますが、グラフを考えるのはとても面白く、コンパイラの仕事を理解するのに非常に役立つことが多いのですが、かなり難しいです。たとえば、知識が不足しているだけでなく、脳の計算能力のために、すべてのグラフを読み取ることはできません（コンパイラオプションは、興味のない動作を取り除くのに役立ちます）。

V8の場合、フラグ付きのD8ツールを使用します--print-ast。Graalの場合はになります--vm.Dgraal.Dump=Truffle:2。テキストが画面に表示されます（グラフを取得するためにフォーマットされます）。V8開発者がビジュアルグラフを生成する方法はわかりませんが、Oracleには、前の図で使用されている「理想的なグラフビジュアライザー」があります。IGVを再インストールする力がなかったので、ソースが閉じられたSeafoamで生成されたChrisSeatonからグラフを取得しました。

では、JavaScriptASTを見てみましょう。

function accumulate(n, a) {
  var x = 0;
  for (var i = 0; i < n; i++) {
    x += a;
  }
  return x;
}

accumulate(1, 1)

d8 --print-ast test.js関数にのみ関心がありますが、このコードを実行しましたaccumulate。一度だけ呼び出した、つまり、ASTを取得するためにコンパイルを待つ必要がないことを確認してください。

ASTは次のようになります（重要でない行をいくつか削除しました）。

FUNC at 19
. NAME "accumulate"
. PARAMS
. . VAR (0x7ff5358156f0) (mode = VAR, assigned = false) "n"
. . VAR (0x7ff535815798) (mode = VAR, assigned = false) "a"
. DECLS
. . VARIABLE (0x7ff5358156f0) (mode = VAR, assigned = false) "n"
. . VARIABLE (0x7ff535815798) (mode = VAR, assigned = false) "a"
. . VARIABLE (0x7ff535815840) (mode = VAR, assigned = true) "x"
. . VARIABLE (0x7ff535815930) (mode = VAR, assigned = true) "i"
. BLOCK NOCOMPLETIONS at -1
. . EXPRESSION STATEMENT at 38
. . . INIT at 38
. . . . VAR PROXY local[0] (0x7ff535815840) (mode = VAR, assigned = true) "x"
. . . . LITERAL 0
. FOR at 43
. . INIT at -1
. . . BLOCK NOCOMPLETIONS at -1
. . . . EXPRESSION STATEMENT at 56
. . . . . INIT at 56
. . . . . . VAR PROXY local[1] (0x7ff535815930) (mode = VAR, assigned = true) "i"
. . . . . . LITERAL 0
. . COND at 61
. . . LT at 61
. . . . VAR PROXY local[1] (0x7ff535815930) (mode = VAR, assigned = true) "i"
. . . . VAR PROXY parameter[0] (0x7ff5358156f0) (mode = VAR, assigned = false) "n"
. . BODY at -1
. . . BLOCK at -1
. . . . EXPRESSION STATEMENT at 77
. . . . . ASSIGN_ADD at 79
. . . . . . VAR PROXY local[0] (0x7ff535815840) (mode = VAR, assigned = true) "x"
. . . . . . VAR PROXY parameter[1] (0x7ff535815798) (mode = VAR, assigned = false) "a"
. . NEXT at 67
. . . EXPRESSION STATEMENT at 67
. . . . POST INC at 67
. . . . . VAR PROXY local[1] (0x7ff535815930) (mode = VAR, assigned = true) "i"
. RETURN at 91
. . VAR PROXY local[0] (0x7ff535815840) (mode = VAR, assigned = true) "x"

これを解析することは困難ですが、パーサーのASTに似ています（すべてのプログラムに当てはまるわけではありません）。そして、次のASTはAcorn.jsを使用して生成されます。

顕著な違いは、変数の定義です。パーサーのASTには、パラメーターの明示的な定義はなく、ループ宣言はノードに隠されていますForStatement。コンパイラレベルのASTでは、すべての宣言がアドレスとメタデータでグループ化されます。

コンパイラASTもこのばかげた式を使用しますVAR PROXY。パーサーのASTは、変数の巻き上げ（巻き上げ）、評価（評価）などのために、名前と変数（アドレスによる）の関係を判別できません。したがって、コンパイラのASTはPROXY、後で実際の変数に関連付けられる変数を使用します。

// This chunk is the declarations and the assignment of `x = 0` 
. DECLS
. . VARIABLE (0x7ff5358156f0) (mode = VAR, assigned = false) "n"
. . VARIABLE (0x7ff535815798) (mode = VAR, assigned = false) "a"
. . VARIABLE (0x7ff535815840) (mode = VAR, assigned = true) "x"
. . VARIABLE (0x7ff535815930) (mode = VAR, assigned = true) "i"
. BLOCK NOCOMPLETIONS at -1
. . EXPRESSION STATEMENT at 38
. . . INIT at 38
. . . . VAR PROXY local[0] (0x7ff535815840) (mode = VAR, assigned = true) "x"
. . . . LITERAL 0

そして、これは、Graalを使用して取得された同じプログラムのASTがどのように見えるかです！

見た目はずっとシンプルです。赤は制御フローを示し、青はデータフローを示し、矢印は方向を示します。このグラフはV8のASTよりも単純ですが、これはGraalがプログラムの単純化に優れていることを意味するものではないことに注意してください。これは、動的性がはるかに低いJavaに基づいて生成されただけです。 Rubyから生成された同じGraalグラフは、最初のバージョンに近くなります。

GraalのASTがコードの実行に応じて変わるのはおかしいです。このグラフは、関数が最適化されないようにランダムなパラメーターを使用して繰り返し呼び出された場合に、OSRを無効にしてインライン化して生成されます。そして、ダンプはあなたにたくさんのグラフを提供します！ Graalは特殊なASTを使用してプログラムを最適化します（V8は同様の最適化を行いますが、ASTレベルでは行いません）。グラフをGraalに保存すると、最適化のレベルが異なる10を超えるスキームが得られます。ノードを書き換えるとき、それらは自分自身を他のノードに置き換えます（専門化します）。

上のグラフは、動的に型指定された言語に特化した優れた例です（OneVMからRuleThem All、2013年に撮影された写真）。このプロセスが存在する理由は、部分的な評価がどのように機能するかに密接に関連しています-それはすべて専門化に関するものです。

Hooray JITがコードをコンパイルしました！もう一度コンパイルしましょう！そしてまた！

上記で「マルチレベル」についてお話しましたが、それについてお話しましょう。考え方は単純です。完全に最適化されたコードを作成する準備がまだできていなくても、解釈にコストがかかる場合は、より最適化されたコードを生成する準備ができたら、プリコンパイルしてから最終コンパイルできます。

Hotspotは、C1とC2の2つのコンパイラを備えた階層型JITです。 C1はクイックコンパイルを実行してコードを実行し、次に完全なプロファイリングを実行してコードをC2でコンパイルします。これは、多くのウォームアップの問題を解決するのに役立ちます。最適化されていないコンパイル済みコードは、とにかく解釈よりも高速です。また、C1とC2はすべてのコードをコンパイルするわけではありません。関数が十分に単純に見える場合、高い確率でC2は役に立たず、実行すらできません（プロファイリングの時間も節約できます！）。 C1がコンパイルでビジー状態の場合、プロファイリングを続行でき、C1の作業は中断され、C2でのコンパイルが開始されます。

JavaScript Coreにはさらに多くのレベルがあります！実際、3つのJITがあります。 JSCインタープリターは、いくつかのライトプロファイリングを実行してから、ベースラインJIT、DFG（データフローグラフ）JIT、最後にFTL（Faster than Light）JITに移動します。非常に多くのレベルがあるため、最適化解除の意味はコンパイラからインタープリターへの移行に限定されなくなり、DFGで始まりベースラインJITで終わる最適化解除を実行できます（これはホットスポットC2-> C1の場合には当てはまりません）。すべての最適化解除と次のレベルへの移行は、OSR（Stack Override）を使用して実行されます。

ベースラインJITは約100回の実行後に接続し、DFG JITは約1000回の実行後に接続します（一部の例外を除く）。これは、JITがコンパイルされたコードを同じPypy（約3000回の実行が必要）よりもはるかに高速に取得することを意味します。階層化により、JITはコード実行の期間を最適化の期間と相関させようとすることができます。各レベルでどのような最適化（インライン化、キャストなど）を実行するかについては、さまざまなトリックがあるため、この戦略が最適です。

JITコンパイラの実装方法

()