【実務・中級編】HHVMのJITにおける「投機的最適化」の失敗と再コンパイル：デオプティマイゼーションを避けるコードの書き方 – Hack言語コア・静的型システムとHHVMのアーキテクチャ解析バイブル

序論：JITが「賭け」に負ける時、あなたのコードは死ぬ

諸君、Hack/HHVMの世界へようこそ。
我々が`hh_client`という厳格な門番を愛しているのは、単にバグを未然に防ぐためだけではない。その真の価値は、実行基盤であるHHVMのJIT（Just-In-Time）コンパイラに対して、最高品質の「ヒント」を与えることにある。

しかし、多くのエンジニアが勘違いしていることがある。
「型チェッカーが通れば、JITは常に最適に動く」という幻想だ。

HHVMのJITは、実行時の型を推論し、特定の型に特化したネイティブコードを生成する「投機的最適化（Speculative Optimization）」を行う。だが、実行時にその推論（賭け）が外れた瞬間、JITは生成したコードを破棄し、低速なインタープリタ実行へ戻るか、あるいは再コンパイルを余儀なくされる。これがデオプティマイゼーション（Deoptimization：脱最適化）だ。

今回は、HHVMの深淵――「ガード失敗」と「再コンパイル」のメカニズムを解き明かし、JITを常に勝ち続けさせるための極限の設計論を伝授しよう。

—

1. HHVM JITの正体：ガード（Guard）とサイド出口（Side Exit）

HHVMのJITコンパイラは、コードをトレースする際、変数の型に対して「ガード」を挿入する。

function add_points(int $a, int $b): int {
return $a + $b;
}

この単純なコードにおいて、JITは「`$a`と`$b`は常に`int`である」という前提で、ダイレクトにCPUのADD命令を叩くマシンコードを生成する。しかし、もし実行時に`mixed`が入り込み、予期せぬ型が渡されると、ガード失敗（Guard Failure）が発生する。

ガード失敗が起きると、実行はサイド出口（Side Exit）へと突き落とされる。
1. 現在のレジスタ状態を保存し、マシンコードの実行を中断。
2. 実行コンテキストをインタープリタに書き戻す。
3. 新しい型プロファイルに基づき、コードを再コンパイルする。

このコストは、通常の関数呼び出しの数百倍に及ぶこともある。高負荷なシステムにおいて、これがループ内で頻発すれば、スループットは劇的に低下する。

—

2. デオプティマイゼーションを誘発する「アンチパターン」

最悪なのは、「静的には正しいが、動的に不安定な型」を多用することだ。

避けるべき設計：不透明な`dict`や`mixed`の乱用

// 非効率なコード：JITを混乱させる「型ガチャ」
function process_payload(dict $data): void {
// $data[‘id’] が int なのか string なのか、JITは実行まで確信が持てない
$id = $data[‘id’];
if ($id is int) {
// ここでJITは int 用のパスを生成するが、
// 次の呼び出しで string が来るとガード失敗が発生する
}
}

`mixed`や動的な`dict`は、JITから見れば「何が来るかわからない地雷原」だ。JITは投機的なコードを生成できず、汎用的で低速なコード（Generic Code）の生成に甘んじることになる。

—

3. JITを掌握する：安定したパフォーマンスのための設計パターン

我々が目指すべきは、「JITが一度生成したコードが、二度と無効化されない設計」だ。

解決策A：`Shape`による構造の固定化

`dict`ではなく`shape`を使え。`shape`はHHVM内部で「構造体」として扱われ、キーの存在と型が静的に保証されるため、JITはメモリオフセットを直接計算できる。

解決策B：タグ付きユニオン（封印されたクラス）による多態性の制御

`mixed`による分岐ではなく、`enum class`や`sealed interface`を用いて、型のバリエーションを明示的に限定せよ。

実践：高効率なAPIレスポンス処理

以下に、実務でそのまま使える「JITに優しい」堅牢なコード例を示す。

ユーザー情報の種類を厳格に定義
sealed interface により、これ以外の実装が存在しないことをJITに確信させる

/
<<__Sealed(VerifiedUser::class, AnonymousUser::class)>>
interface UserProfile {
public function getID(): int;
}

final class VerifiedUser implements UserProfile {
public function __construct(private int $id, private string $email) {}
public function getID(): int => $this->id;
}

final class AnonymousUser implements UserProfile {
public function getID(): int => 0;
}

構造化されたデータ(Shape)を用いることで
JITはハッシュテーブルのルックアップをスキップし、メモリアドレスへ直行する

/
type UserContext = shape(
‘profile’ => UserProfile,
‘request_id’ => string,
);

final class UserProcessor {
/

投機的最適化を最大限に活かすメソッド
パラメータがインターフェースで制限されているため、
JITは「VTableルックアップ」を高度に最適化できる

/
public static async function processAsync(UserContext $ctx): Awaitable {
$profile = $ctx[‘profile’];
$id = $profile->getID(); // JITはここでの型を容易に予測可能

if ($id === 0) {
// 匿名ユーザー向けパス
return;
}

// 非同期処理でも型安全性とJITの安定性を維持
await self::logAccessAsync($id, $ctx[‘request_id’]);
}

private static async function logAccessAsync(int $id, string $rid): Awaitable {
// ログ出力処理…
}
}

—

4. プロフェッショナルの視点：なぜこのコードが「速い」のか

1. `__Sealed` による最適化の固定:
`UserProfile`の実装が2つしかないことをJITが知っているため、JITは「インラインキャッシュ（Inline Cache）」を極限まで最適化できる。もし実装が1つしかなければ、JITは関数呼び出しそのものを消し去り、インライン化するだろう。
2. `Shape` の定数時間アクセス:
`dict`は実行時にキーのハッシュ計算が必要だが、`shape`はコンパイル時にオフセットが決まる。これはPHPの配列操作とは比較にならないほど高速だ。
3. 型ガードの最小化:
`int`や`string`を明確に定義することで、JITは「これは本当にintか？」というチェック（ガード）を最小限に抑えた、直線的なマシンコードを出力できる。

—

結論：コードはJITへの「誓約書」である

Hackを書くということは、単に型チェッカーを黙らせることではない。HHVMのJITコンパイラに対し、「この変数の型は未来永劫変わらない」という契約を結ぶ行為なのだ。

`mixed`を捨てよ。
動的な`dict`を`shape`に置き換えよ。
`sealed`を使って多態性の範囲を限定せよ。

君たちがこの原則を守る限り、HHVMは期待に応え、限界を超えたパフォーマンスを叩き出してくれるはずだ。逆に、曖昧な型を放置すれば、システムはデオプティマイゼーションの泥沼に沈むだろう。

どちらを選ぶかは、君たちのアーキテクチャ設計次第だ。
ハッピーハッキング。