HHVM JITの深淵：PHP/Hackコードがいかにしてx64マシン語へ昇華されるか
ランタイムエンジンの内部構造に興味を持つエンジニアであれば、一度は立ち止まる問いがある。「動的言語の皮をかぶったHackが、なぜC++並みのスループットを叩き出せるのか」と。
世間一般の入門記事は「バイトコードにコンパイルされて、JITで機械語になります」という抽象論で筆を置く。だが、シニアエンジニアやセキュリティ研究者が知りたいのはそこではない。ASTからHNI、Unit、そしてTC（Translation Cache）に至るバイナリのライフサイクルであり、型情報がJITの最適化パイプラインでどう武器として使われているかの実態だ。
今回は、HHVM（HipHop Virtual Machine）がソースコードをネイティブのx64マシン語へと変貌させるまでの4つのフェーズを、ランタイムの深部から解き明かしていく。
—
1. 構文解析とバイトコード生成フェーズ（Unitの誕生）
すべての始まりは、ソースコードのパースだ。Hackの厳格な型システム（`strict` モード）は、この段階ですでにランタイムに対して強力なヒントを提供している。
ヒューリスティックな推論に頼るPHP 7/8のJITとは異なり、Hackの型チェッカー（hh_client）とHHVMのフロントエンドは緊密に連携している。ソースコードはパーサによってAST（抽象構文木）へと落とし込まれ、即座に `Unit` と呼ばれるバイナリ表現にコンパイルされる。
この `Unit` こそが、関数、クラス、グローバル定数、そしてバイトコード（Opcode）のコンテナである。
// 例：厳格な型付けが施されたHackの関数
namespace ExtremeJIT;
<<__EntryPoint>>
function main(): void {
$a = 42;
$b = 100;
// この単純な加算ですら、型情報がUnitのオペコードに刻まれる
$result = add_i64($a, $b);
echo “Result: {$result}\n”;
}
function add_i64(int $x, int $y): int {
return $x + $y;
}
この段階で生成されるバイトコードは、従来のZend VMのそれとは異なり、スタックベースではなくレジスタベースに近い仮想マシン命令に近い。HHVMのバイトコード（HHBC）は、静的解析が容易なように設計されており、型制約（Type Hints）はそのままオペランドのメタデータとして `Unit` の中に焼き付けられる。
—
2. インタープリトとプロファイリングフェーズ（TCへの布石）
`Unit` がロードされると、HHVMは最初からマシン語を生成するわけではない。初期状態では、コードは HPHPc/HHVMのインタープリタ によって実行される。
ここで重要な役割を果たすのが、プロファイラ（Profiler）だ。
インタープリタがバイトコードを実行する裏で、ランタイムは静かにデータを収集している。
- どの関数がホットスポット（高頻度で実行されるループや関数）か？
- 変数の型は常に一定か？（PolymorphicかMonomorphicか？）
- プロパティのアクセスパターンは予測可能か？
HHVMのJITは、いわゆる「オポチュニスティック（日和見主義的）」なJITではない。型情報が明確なHackにおいては、プロファイリング結果は「型が揺らがないことの証明」として機能し、次のフェーズであるIR生成への切符となる。
—
3. 翻訳フェーズ：HHIR（HipHop Intermediate Representation）への変換
ホットスポットが検出されると、JITの心臓部であるTranslatorX64（TransX64）が動き出す。ここからが真の低レイヤの領域だ。
バイトコードは直接x64に落ちるわけではない。一度、HHIR（HipHop Intermediate Representation）と呼ばれる静的単一代入（SSA）形式の中間表現に変換される。
このHHIRのレイヤで、以下のようなアグレッシブな最適化が行われる。
1. Type Specialization（型の特殊化）:
Hackのコードで引数が `int` と明示されていれば、HHIRは「これが整数である」という絶対的な前提のもとで処理を構築する。Zend VMのように「今渡された値は整数か？オブジェクトか？」を毎回判定するガード（Guard）コードの多くを省くことができる。
2. Dead Code Elimination (DCE) & Inlining:
使われない分岐の削除や、小さな関数のインライン展開がSSAのグラフ上で行われる。
セキュリティ研究者の視点で特筆すべきは、このHHIRがメモリ安全性を担保しつつ、CPUのパイプラインを極限まで効率化する命令列へとプレパレーションされる点だ。
—
4. コード生成とTC（Translation Cache）への焼き付け
最適化されたHHIRは、最終的にx64アセンブリ言語へと翻訳され、CPUが直接実行可能なマシン語になる。
生成された機械語は、プロセスのアドレス空間内にある専用のメモリ領域である TC（Translation Cache） に書き込まれる。TCは、OSのメモリ保護において `PROT_READ | PROT_WRITE` で生成されたのち、書き込みが完了すると `PROT_EXEC`（W^Xポリシーの厳格な適用）へと切り替わられ、安全に実行される。
[Hack Source Code]
↓ (Parser & Compiler)
[Unit / HHBC]
↓ (Interpreter & Profiler – Hotspot Detection)
[HHIR (SSA Intermediate Representation)]
↓ (TransX64 Optimizer)
[Translation Cache (TC) -> x64 Native Machine Code]
CPUがジャンプ（`jmp` または `call`）によってTC内のアドレスに飛び込んだ瞬間、PHP/Hackコードは、C++やRustで書かれたネイティブバイナリと遜色ない速度でCPUの演算器を叩き始める。
—
実践：型システムがJITに与える爆発的な影響
百聞は一見にしかず。Hackの型システムがJITの生成するコード品質にどう直結するか、以下のベンチマーク的コード片で思考実験してみよう。
<<__EntryPoint>>
function benchmark(): void {
$total = 0;
// 厳密な型がついたループ
for ($i = 0; $i < 10_000_000; $i++) {
$total += $i;
}
echo "Sum: {$total}\n";
}
動的言語（PHP等）の挙動
1. `$total` と `$i` の加算のたびに、両者がZend Value（数値型タグを持つ共用体構造体）であるかチェックする。
2. オーバーフローが発生した場合は、自動的に浮動小数点（Float）や任意精度整数への昇格（Promote）処理が挟まる。
3. ループのインラインキャッシュ（IC）がヒットし続ける保証はない。
Hack + HHVM JITの挙動
1. `$total` と `$i` が共に `int`（64ビット符号付き整数）であることが静的に確定しているため、JITは単なるCPUの `add rax, rbx` 命令にコンパイルする。
2. 型チェックのオーバーヘッド（Box/Unboxのコスト）は完全に消滅する。
3. ループカウンタのインクリメントと加算は、レジスタ内だけで完結する。
これが、Hack言語が大規模なMeta（旧Facebook）のコードベースにおいて、動的言語の開発生産性を維持しながら、静的言語に匹敵するパフォーマンスを叩き出せる理由の核心である。
—
チーフアーキテクトからの提言
JITコンパイラは魔法の箱ではない。それは「開発者がコードに込めた意図（型や構造）」を最大限に抽出し、CPUの物理的限界へと翻訳するための精緻なパイプラインだ。
Hackの静的型システムを軽視し、「どうせ動くから」と `mixed` や曖昧な型付けを蔓延させれば、JITはプロファイリングの段階で悲鳴を上げ、ガード（Guard）失敗によるTCからの脱出（Deoptimization）が頻発する。結果として、ランタイムはネイティブ実行からインタープリタへのフォールバックを余儀なくされ、パフォーマンスは地に落ちる。
コードを書くときは常に想像せよ。あなたの書いたその1行が、HHIR上でどのように表現され、TC上のどのx64命令列に落ちるのかを。その解像度を持ったエンジニアだけが、Hackの真のポテンシャルを解放する資格を持つ。