JITの「裏切り」を飼い慣らせ：HHVMデオプティマイゼーションの深淵と回避術
Hackを単なる「PHPの亜種」だと思っているなら、今すぐその認識を捨てろ。HHVMは、静的型システムと動的JIT実行エンジンの境界線上で、常に「推論」という名の賭けを行っている。
我々が書くコードがどれほど厳格な型定義を持っていても、HHVMのJITコンパイラが実行時に生成するマシンコードは、ある前提条件に基づいた「投機的最適化」の産物だ。この前提が崩れた瞬間、エンジンは「デオプティマイゼーション（Deoptimization）」という名の緊急停止を強いられる。
今日は、JITの「裏切り」を最小化し、実行速度を極限まで安定させるためのアーキテクチャ設計について語る。
—
1. なぜJITは「推論」に失敗するのか？
HHVMのJITは、プロファイリングデータに基づいて「このコードは常にこの型で回るはずだ」という推論を行う。しかし、この推論が外れると、以下のコストが発生する。
1. ガード（Guard）の失敗: JITが挿入した型ガードが外れる。
2. VMへの復帰（Exit to VM）: 最適化されたマシンコードから、低速なインタープリタやVMの汎用ロジックへ強制的に制御が戻る。
3. 再コンパイル（Re-compilation）: 失敗した地点で、新たな型情報を元に再コンパイルが走る。
これが「デオプティマイゼーション」だ。特にループ内での型変化は、CPUのパイプラインを破壊し、パフォーマンスを奈落へ突き落とす。
—
2. デオプティマイゼーションを避ける「純潔」なコード設計
実務で最も避けたいのは、「多相性（Polymorphism）の過剰な汚染」だ。一つの関数に異なる型のオブジェクトを流し込むな。
悪い設計：型が揺らぐ「汚れた」関数
// ダメな例：型の不一致がJITのガードを破壊する
function processData(mixed $input): void {
// $inputがintの時とstringの時で、JITのガードが頻繁に外れる
if ($input is int) {
// … 処理
} else if ($input is string) {
// … 処理
}
}
このコードは、型ガードを何度も発生させ、JITコンパイラを混乱させる。
良い設計：型を分離した「純潔」なインターフェース
// 良い例：明確な型分離でJITの推論を安定させる
interface Processor {
public function execute(): void;
}
final class IntProcessor implements Processor {
public function __construct(private int $val) {}
public function execute(): void { / int専用の高速な最適化が適用される / }
}
final class StringProcessor implements Processor {
public function __construct(private string $val) {}
public function execute(): void { / string専用のコードが生成される / }
}
なぜこれが速いのか？
HHVMは `Processor::execute()` が呼ばれる際、呼び出しサイトごとに特定の具象クラスに特化したコードをインライン展開できるからだ。型がブレないため、JITは安心して最適化を深められる。
—
3. 実践：非同期API連携における「型の一貫性」
非同期処理（`Awaitable`）においても、結果の型が不安定だとJITは最適化の機会を失う。特に、APIレスポンスのパース時が鬼門だ。
// 堅牢なプロダクションコードのパターン
final class ApiResponse {
public function __construct(
public readonly int $code,
public readonly vec
) {}
}
async function fetchAndProcess(string $url): Awaitable
$response = await callApi($url);
// 構造化された型への変換を明示し、実行時の型揺らぎを排除する
// これにより、後続の処理でJITはApiResponseのメモリレイアウトを完全に把握できる
return new ApiResponse(
(int)$response[‘code’],
vec($response[‘items’] ?? []),
);
}
—
4. 伝説のアーキテクトからの助言
JIT最適化を味方につけるためのチェックリストを授ける。
- `mixed` を撲滅せよ: `mixed` はJITにとって「地雷原」だ。可能な限り `shape` や `vec`、`dict` で型を具体化せよ。
- ループ内の型推論を信じるな: ループ内で変数の型を変えるな。変える必要があるなら、それは関数を分割すべきサインだ。
- `final` を積極的に使え: クラスやメソッドを `final` にすることで、HHVMは仮想テーブル（vtable）のルックアップを回避し、静的な呼び出しに置換（Devirtualization）できる。これは劇的な高速化をもたらす。
最後に：コードは「機械への手紙」である
Hackは、単にコードを書く言語ではない。君たちが書いたコードは、HHVMという巨大な機械に対する「詳細な指示書」だ。君たちが型を曖昧にすれば、機械は迷い、立ち止まる。君たちが型を研ぎ澄ませば、機械は光の速さで答えを出す。
デオプティマイゼーションを恐れるな。その背後にあるメカニズムを理解し、JITが最も輝く道筋をコードで描いてやれ。それが、エンジニアとしての「掌握」だ。
さあ、エディタを開け。君のコードは、まだ最適化できるはずだ。