HHVMの深淵：JITデッドコード除去の「見えない壁」と、我々が実装で奪還すべき最適化の主導権
HHVMのJITエンジンは、単なるバイトコードの実行器ではない。プロファイリング情報を元にした適応型最適化（Adaptive Optimization）の結晶だ。しかし、多くのシニアエンジニアが勘違いしていることがある。「HHVMが賢いから、動かさないコードはいつか消えるだろう」という過信だ。
結論から言えば、HHVMのJITによるデッドコード除去（DCE）には、理論的かつ実務的な「限界」がある。本稿では、コンパイラの内部挙動を突き抜け、我々アーキテクトがいかにしてランタイムの負荷を物理的に削ぎ落とすべきかを説く。
—
1. JITの限界：なぜ「静的解析」だけでは不十分なのか
HHVMのJITは、実行時に生成される `IR (Intermediate Representation)` に対してDCEをかける。しかし、以下の構造的ボトルネックにより、JITは意図的に「消せないコード」を抱え込む。
- 動的ディスパッチと観測可能性: Hackは動的な型評価を内包する。特定の抽象クラスの実装が将来的にロードされる可能性を考慮すると、コンパイラは「そのコードが将来的に到達不可能である」と証明できない。
- ガード条件の複雑性: HHVMのトレース最適化は、プロファイリングデータに基づいた「推論」を行う。分岐の片方が稀にしか実行されない場合、コンパイラはそれを除去するよりも、ガード（Guard）を配置してフォールバックさせるコストを選択する。
- 副作用の不透明性: 関数が外部状態（グローバル変数やインジェクションされたリソース）に依存していると判断された瞬間、DCEは保守的になり、無用な命令がメモリ上に残り続ける。
—
2. 現場で直面する「ゾンビコード」の正体
我々が書く Hack コードの中で、最も厄介なのは「条件分岐の深淵に潜むDead code」だ。
<<__EntryPoint>>
function process_data(mixed $input): void {
// JITにとっては「ガードの連続」になりやすい構造
if ($input is int) {
handle_int($input);
} else if ($input is string) {
handle_string($input);
} else {
// ここはJITの観点では「到達可能」とマークされ続け、
// メモリ内の命令キャッシュ(i-cache)を汚染する
log_error(“Unknown type”);
}
}
この `log_error` は、特定の条件下では完全に不要だ。しかし、HHVMは `mixed` 型の不確実性を排除しきれないため、このブランチをIRから完全にパージすることは困難である。結果、JITコンパイルされたバイナリ内には、実行されないにもかかわらず「いつでも動ける状態」で待機する命令群が居座る。
—
3. 限界を突破する：アーキテクトのための「コード・トリアージ」
JITコンパイラに過度な期待を寄せるのは、エンジンに対する冒涜だ。我々がとるべきは、「コンパイラが論理的に除去せざるを得ない構造」をコードレベルで強制することである。
戦略A：`__PHP__IsType` の活用と型による枝刈り
HHVMの型チェッカーを最大限に利用し、コンパイラに対して「この分岐は論理的に存在しない」と突きつける。
// 非推奨: 曖昧な型判定
if ($x is MyInterface) { … }
// 推奨: 枚挙型やSealedクラスによる「網羅性の証明」
enum Status: int {
Active = 1;
Inactive = 2;
}
function handle(Status $s): void {
// コンパイラは「これ以外の値は存在しない」ことを静的に確信できる
// その結果、defaultケースや予期せぬ分岐のコードはIR生成段階で排除される
switch ($s) {
case Status::Active: …; break;
case Status::Inactive: …; break;
}
}
戦略B：プロファイリングの汚染を防ぐ「ホットパス分離」
JITエンジンは、頻繁に実行されるコードを「ホット」と見なし、最適化の優先度を上げる。めったに実行されないエラーハンドリングやバックグラウンド処理は、積極的に別関数へ抽出せよ。
- 理由: 関数サイズが肥大化すると、JITのインライン展開（Inlining）アルゴリズムが制限を受け、最適化の余地が狭まる。関数を小さく分けることは、CPUの命令キャッシュミスを減らすための最も原始的かつ強力な最適化だ。
—
4. チーフアーキテクトからの提言：メモリを支配せよ
JITが生成するマシンコードは、サーバーのRAMを食いつぶす。我々がすべきは、「JITにとって心地よいコード」を書くことだ。
1. ポリモーフィズムの低減: 巨大な継承ツリーは、仮想関数テーブル（vtable）の探索コストを増大させる。可能であれば `shape` や `enum` を活用し、ディスパッチを静的なものに書き換えよ。
2. 不変性の強制: `readonly` プロパティなどを活用し、コンパイラに「この値は実行中に変わらない」という確信を与えよ。確信があれば、コンパイラは値をレジスタに直接埋め込む（定数畳み込み）ことが可能になる。
3. デッドコード除去の計測: `hhvm.jit.dump_ir` 等のフラグを使い、本番同等のワークロードで生成されるIRを確認せよ。IRの中に不要なラベルが溢れているなら、それはあなたの設計がランタイムに余計な負荷をかけている証拠だ。
—
最後に：完璧な最適化は存在しない
HHVMは進化し続ける。しかし、コンパイラの進化を待つよりも、開発者が「計算機が実行する命令の重み」を理解し、不要なパスを論理的に抹殺する姿勢こそが、最高性能を引き出す鍵となる。
Hackは、単なるスクリプト言語ではない。静的型システムという名の「コンパイラへの命令書」を駆使し、ハードウェアを制御するエンジニアのための武器だ。コードを消せ。不要な分岐を排除せよ。その先にだけ、高負荷環境を支配する真のパフォーマンスが待っている。