JITの背信：HHVMにおけるデオプティマイゼーションの深淵と、型による防壁
HHVMのJITコンパイラは、単なるバイトコードの機械語翻訳機ではない。それは実行時の動的なプロファイリングに基づき、推論された「型」という名の仮説を信じ切る、極めてアグレッシブな投機的エンジンだ。
しかし、このエンジンが最も嫌うのは「裏切り」である。JITが生成した最適化済みコード（Machine Code）が前提としていた型を、実行時に変数が覆す。このとき、HHVMは血の涙を流しながら「デオプティマイゼーション（Deoptimization）」という名の撤退戦を強いることになる。
本稿では、この極限のランタイム挙動を掌握し、なぜあなたのコードがパフォーマンスの深淵に落ちるのかを解き明かす。
—
1. 投機的最適化という名の博打
HHVMのJITは、熱いコードパスを特定し、そこにある変数の型を「現時点での経験則」から断定する。例えば、ある関数が常に `int` を返すなら、JITはそれをレジスタレベルで完結する命令へと変換する。
だが、もし次に呼び出された際に `string` が混入したらどうなるか。
1. Guard Failure: JITが挿入した「型チェック用のガード命令」が、型の不一致を検知する。
2. Side Exit: CPUは最適化されたコードから弾き出される。
3. Deoptimization: 実行コンテキストがインタープリタ（あるいは低速な再コンパイル・パス）へ巻き戻される。
この「巻き戻し」は、単なる速度低下ではない。CPUキャッシュの汚染、コンテキストスイッチ、そして再コンパイルのためのプロファイリング・オーバーヘッドという、三重のペナルティを課す。
2. 破滅を招く「型推論の曖昧さ」
最も避けるべきは、Hackの型チェッカーをすり抜けるような「曖昧な設計」だ。
アンチパターン：Any型と混在型への依存
// 悪い例: 混合型がJITのガードを過多にする
function process(mixed $data): void {
// $dataがintかstringかによって、JITは二通りのコードパスを保持しなければならない
// 型の揺らぎが大きいと、JITは最適化を諦め、汎用的な遅いパスを選択する
print (string)$data;
}
このコードでは、`$data` の型が特定できないため、JITは「ガード命令」をループのたびに発行することになる。これが積み重なると、CPUの分岐予測（Branch Prediction）は破綻し、パイプラインはストールする。
3. 回避の極致：型の厳格化によるJITの安寧
JITに「疑い」を抱かせないこと。それがアーキテクトとしての防壁だ。以下の戦略こそが、HHVMのポテンシャルを極限まで引き出す。
A. Union Type の排除と Shape の活用
`mixed` や `?T` を多用することは、JITに「ここには何が入るかわからない」と告げるに等しい。可能な限り具体的な Shape 型や Class を定義し、型推論の境界を明確にせよ。
// 良い例: 構造を確定させる
shape(
‘id’ => int,
‘payload’ => string,
) $data;
// これにより、JITは構造体のオフセットを事前に定数としてハードコードできる。
// メモリ読み取り時のレイテンシを最小化できる。
B. 頻繁な型変換（Cast）の禁止
キャストはランタイムのオーバーヘッドであるだけでなく、JITにとっては「型の遷移点」を強制的に作る行為だ。JITが追跡すべき型変遷グラフをシンプルに保つことが、安定した高速化に繋がる。
4. メモリ管理とアライメントの視点
HHVMの内部では、データは `TypedValue` という構造体で管理されている。型が一致していれば、JITは値（`int` や `bool` など）をレジスタに直置きできるが、型が不定だとメモリ上のヒープを辿るポインタ参照が発生する。
- 型が確定している場合: CPUレジスタ内での算術演算（1クロック未満）。
- 型が不明な場合: ヒープからのロード、型タグの確認、分岐命令（数十〜数百クロック）。
この差が、スループットの決定的な分水嶺となる。
結びに：伝説的なアーキテクチャへの敬意
HHVMのJITを飼いならすことは、コンパイラの精神的支柱を理解することに他ならない。あなたが書く一行のHackコードは、最終的に機械語の命令列に変換される。
型とは単なるドキュメントではない。それは、「このメモリ領域にはこの値しか存在しない」という、ランタイムエンジンに対する極めて重い契約書である。その契約を厳格に守り抜く者だけが、HHVMの真の力を引き出し、システムを限界のその先へと押し上げることができる。
最適化とは、魔法ではない。論理的な帰結である。さあ、コードを再構築し、JITの心を掴め。