【HHVM内部探訪】JITを減速させる「デオプティマイゼーション」の正体と、型推論を助ける美しいHackコードの書き方
こんにちは！ HackとHHVMの深遠な世界へようこそ。
PHPからステップアップしてきた方や、TypeScript、Java、Rustなどの静的型付け言語からHackに触れ始めた方なら、Hackの「型安全なのにスクリプト言語のようにサクサク動く」という魅力に驚いているのではないでしょうか。
その高速性を舞台裏で支えているのが、HHVM（HipHop Virtual Machine）が誇るJIT（Just-In-Time）コンパイラです。
しかし、時には「型をなんとなく書いた」せいで、HHVMのJITが悲鳴を上げ、パフォーマンスが急降下してしまう現象が存在します。それが今回のテーマである「デオプティマイゼーション（Deoptimization: 最適化解除）」、通称Deopt（デオプト）です。
「JITの内部構造なんて難しそう……」と身構える必要はありません！
仕組みと対策さえ押さえれば、誰でもJITと心を通わせた最高速のコードが書けるようになります。「ここをクリアすれば、Hackの基本はバッチリマスター」と言える重要な境界線を、一緒に楽しく紐解いていきましょう！
—
1. HHVM JITの思考回路：なぜ「投機」するのか？
HHVMは、プログラムが実行されている最中に、頻繁に呼ばれるコード（ホットスポット）をネイティブな機械語（マシンコード）へと変換します。このとき、HHVMは「投機的最適化（Speculative Optimization）」という大胆な戦略をとります。
JITの思考を覗いてみる
たとえば、次のような単純な加算処理を見たとしましょう。
function add(mixed $a, mixed $b): mixed {
return $a + $b;
}
人間が見ると「`$a` も `$b` も何が入るかわからないな」と思いますが、HHVMは過去の実行履歴（プロファイリング情報）を見てこう推論します。
> HHVMの心の声:
> 「ふむ……過去1万回この関数が呼ばれたけれど、全部 `$a` も `$b` も整数（int）だったぞ。
> よし！ おそらく次も `int` に違いない！
> 面倒な型チェックは全部スキップして、CPUの加算命令（`ADD`）1発で動く超高速マシンコードを作っちゃおう！」
これが投機（Speculation：ヤマを張ること）です。
そこで立ちはだかる「ガード（Guard）」
しかし、もし1万1回目に文字列や小数が渡されたら、マシンコードはクラッシュしてしまいます。そのため、JITはコードの先頭に小さな門番を配置します。これを型ガード（Type Guard）と呼びます。
[マシンコード領域]
│
▼
【型ガード】「おい、$a と $b は今回も int だろうな？」
│
├─(YES: 予想的中！) ───► [超高速な加算マシンコードを実行！] ──► 完了
│
└─(NO: 予想外！) ─────► 【ガード失敗（Bailout発生！）】
│
▼
[インタープリタへ強制送還（Deopt）]
—
2. デオプティマイゼーションの恐怖：何が起きているのか？
ガードが失敗した瞬間、HHVMは「ああっ！ 予想が外れた！」とパニックになり、ネイティブコードの実行を即座に中断します。これをBailout（ベイルアウト：緊急脱出）と呼びます。
そして、安全に処理を続行するためにインタープリタ（低速だがどんな型でも処理できる実行器）へ処理を戻すのです。この一連の巻き戻しプロセスこそがデオプティマイゼーションです。
デオプトが高コストな理由
「単に遅いインタープリタに戻るだけでしょ？」と思うかもしれませんが、実は裏側では凄まじいオーバーヘッドが発生しています。
1. CPUパイプラインの破壊: CPUが先読みしていた命令がすべて破棄されます。
2. コンテキストの再構築: レジスタ上に展開されていた変数の値を、インタープリタが解釈できる仮想マシン（HHBC）のスタック形式へと手作業で詰め直します。
3. メタデータの消費: 再びJITコンパイルし直すためにプロファイリングをやり直す必要があり、メモリとCPU時間を激しく浪費します。
つまり、デオプトが頻発するコードは、JITなしで動かすよりも圧倒的に遅くなるのです。
—
3. 型推論を失敗させる3大アンチパターン
では、どのようなコードがガード失敗や型推論の敗北（Deopt）を引き起こすのでしょうか？ 初学者が陥りがちなパターンを見てみましょう。
パターン1：`mixed` や `dynamic` の乱用による実行時ブレ
// ⚠️ 避けたほうがよい例：戻り値が曖昧
function calculateDiscount(bool $is_vip, int $price): mixed {
if ($is_vip) {
return $price 0.8; // float を返す
}
return $price; // int を返す
}
function processOrders(vec
foreach ($prices as $p) {
// JITは「$discount は float なのか？ int なのか？」で常にガードを張り替える
$discount = calculateDiscount(true, $p);
echo $discount;
}
}
解説:
`calculateDiscount` の戻り値が `int` と `float` の間を行き来しています。静的型チェッカー（`hh_client`）は `mixed` だからと通過させてくれますが、HHVMのJITエンジンは実行時に「今回はfloat」「今回はint」と振り回され、最適化したマシンコードを破棄し続けます。
—
パターン2：ループ内での「暗黙のnull変化」
// ⚠️ 避けたほうがよい例：ループ内で型が変化する
function findFirstValid(vec $items): string {
$result = null; // 最初は null 型として追跡される
foreach ($items as $item) {
if ($item !== null) {
$result = $item; // ここで突然 string に変化！
break;
}
}
return $result ?? “default”;
}
解説:
変数の型がループの途中で `null` から具象型へと変貌を遂げると、JITはループ開始時に立てた「この変数は `null` である」という仮説を途中でへし折られます。
—
パターン3：要素の型が定まらないコレクション
// ⚠️ 避けたほうがよい例：型が混在したコレクション
function logData(): void {
// vecの中に int と string が同居している
$data = vec[100, “200”, 300, “400”];
foreach ($data as $val) {
// JITはイテレーションごとに型ガードを評価しなければならない
takeIntOrString($val);
}
}
解説:
要素型が統一されていないコレクションを反復処理すると、ループ内のJITコードは毎回ガードチェックに失敗し、最適化されたループアンローリング（ループ展開）などの強力な恩恵を一切受けられなくなります。
—
4. JITを最高速で走らせる「Deopt回避」の型設計
Deoptを防ぎ、JITに「迷いのない超高速コード」を生成させるためのアプローチは実はとてもシンプルです。「Hackの静的型チェッカーの力を極限まで信じ、厳格に書くこと」。これに尽きます。
処方箋1：Union型を使わず、意図を明確にする
先ほどの割引計算は、型を厳格にすることで劇的に改善します。
<<__EntryPoint>>
function main(): void {
// 正しい例：戻り値を float に統一する
$calc = (bool $is_vip, int $price): float ==> {
if ($is_vip) {
return (float)$price 0.8;
}
// int をそのまま返さず、一貫して float を返す
return (float)$price;
};
$prices = vec[1000, 2000, 3000];
foreach ($prices as $p) {
// JITは「$discount は絶対に 100% float だ」と確信して
// ガードを最小化し、浮動小数点レジスタ（XMMなど）を直結できる！
$discount = $calc(true, $p);
\printf(“Price: %.2f\n”, $discount);
}
}
処方箋2：コレクション型にはジェネリクスを厳格に指定する
配列を扱う際は、常に中身の型を明示しましょう。
// ⭕️ 素晴らしい例：型が単一に定まったコレクション
function processUserIds(vec
$sum = 0;
// HHVMはループカウンタと加算処理を純粋なネイティブ整数演算にコンパイルする
foreach ($ids as $id) {
$sum += $id;
}
return $sum;
}
HHVMは `vec
—
まとめ：静的型付けは「JITへのラブレター」
Hackを書き始めたばかりの頃は、「型チェックを通すのが面倒だな……」と感じる瞬間があるかもしれません。
しかし、HHVMのアーキテクチャの視点に立つと、あなたが書いた厳格な型定義は、JITエンジンに向けた「ここは疑わずにフルスピードで突っ走っていいぞ！」という最高の信頼の証（ラブレター）なのです。
- `mixed` や `dynamic` を極力減らし、具象型を使う
- 関数の戻り値の型を、条件分岐によってブレさせない
- コレクション（`vec`, `dict`, `keyset`）の要素型を一貫させる
この3つのポイントを意識するだけで、あなたのHackコードは型安全になるだけでなく、HHVM JITが叩き出す真のポテンシャル――極限のパフォーマンスを発揮するようになります。
焦らず一歩ずつ、JITと呼吸を合わせる美しいコードを書いていきましょう。これがマスターできれば、あなたはもう立派なHackエンジニアです！