HHVM JITの深淵：静的解析が「殺せない」コードをどう飼い慣らすか
HHVMのJITエンジンは、単なるバイトコードの実行器ではない。プロファイリング情報を元に動的にマシンコードを生成し、推論に基づいた投機的最適化（Speculative Optimization）を繰り返す、極めて攻撃的なランタイムだ。
しかし、どれほどHHVMが進化しようとも、「コンパイラが論理的に削除できないコード」は存在する。本稿では、HHVMがなぜ最適化に失敗するのか、そしてその「限界」をエンジニア側がどうハックすべきか、低レイヤの視点から紐解く。
—
1. JITが「デッドコード」を認識できない理由
HHVMのJIT最適化フェーズ（特にHHIR – HHVM Intermediate Representation）において、コードの削除が阻害される最大の要因は「副作用の不可視性」と「動的ディスパッチの不確実性」だ。
静的解析において、以下のパターンはJITにとって「地雷」となる。
- マジックメソッドと動的プロパティ: `__get`, `__set`, `__call` を介したアクセスは、ランタイムでの解決が必要であり、JITは「このコードが本当に不要か」を決定論的に証明できない。
- インターフェースを介した広範なポリモーフィズム: 呼び出し先が実行時にしか確定しない場合、JITはガード（Guard）を挿入せざるを得ない。ガードの存在自体が、コードをメモリ上に留まらせる原因となる。
- Reflection APIの利用: リフレクションによるメタデータ操作が介在すると、コンパイラは「そのクラスが将来的にリフレクションで呼ばれる可能性」を排除できず、最適化を諦める。
2. 実行時オーバーヘッドを生む「死んだコード」のパターン
典型的なのが、大規模なコードベースで放置された「型チェックのための冗長なガード」だ。
// 典型的なアンチパターン
function processData(mixed $input): void {
// 既にHackの型システムで制約されているにも関わらず、
// 防御的プログラミングとして書かれた冗長なチェック
if ($input is string) {
$this->handleString($input);
} elseif ($input is int) {
$this->handleInt($input);
}
// ここで発生する”else”節が、JITにとっては実行パスとして
// 常にメモリにロードされ続ける無駄な分岐となる
}
HHVMは、この`if-else`の分岐を「実行頻度が低い」と判断すれば、ベースライン実行（低コスト）へ追いやり、さらに低頻度であればコードキャッシュから追い出す。しかし、キャッシュの断片化（Cache Fragmentation）は避けられない。
3. 「限界」を突破するためのリファクタリング戦略
JITがコードを削除できないなら、「JITが容易に削除できる形式」にコードを再構築するのが正攻法だ。
戦略A：`sealed`インターフェースによる推論の極大化
`sealed`修飾子を使い、継承関係を閉じることで、JITは仮想メソッドテーブル（vtable）の探索を回避し、デバブルな直結呼び出しに最適化できる。
<<__Sealed(A::class, B::class)>>
interface Processor {}
final class A implements Processor { public function run(): void { / … / } }
final class B implements Processor { public function run(): void { / … / } }
// こうすることで、HHVMは推論エンジンに対し「このインターフェースの
// 実装はAかBしかない」と断定させ、型ガードを排除したマシンコードを生成する。
戦略B：`__PHPStdLib` 属性の活用とインライン化
ホットパスにある関数には、意図的に型ヒントを厳格化し、HHVMがインライン展開（Inlining）しやすくする。インライン展開は、関数呼び出しのオーバーヘッドを消すだけでなく、呼び出し先コードと呼び出し元コードを統合し、デッドコード除去（DCE）のスコープを拡大する効果がある。
戦略C：`__EntryPoint` との分離
不要な初期化コードやセットアップロジックは、ブートストラップ処理から完全に分離し、`memoize`属性を適切に使うことで、計算結果を静的メモリに固定する。JITは「定数である」と確信した瞬間に、その計算ロジック自体をコンパイル結果から消し去ることができる。
4. 伝説的なチューニング：HHVMのプロファイリングを活用する
`hhvm.jit_profile_on_demand=1` を活用し、実際のトラフィックでどのパスが「Dead」と見なされているかを確認せよ。
もしあなたが大規模なHHVMクラスタを運用しているなら、`-vEval.JitProfileLease=1` を確認し、JITが生成したマシンコードのサイズを監視すべきだ。コードサイズが膨れ上がっている箇所は、ほぼ確実に「静的解析が最適化を諦めた箇所」である。
結びに：コンパイラを信頼し、制御せよ
HHVMのJITは魔法ではない。それはメモリとCPU時間を天秤にかけ、ヒューリスティックに最適な解を導き出す計算機だ。
あなたが書くHackコードが「JITにとって推論しやすい」とき、ランタイムは最大限のパフォーマンスを報いてくれる。型定義を曖昧にせず、継承を制限し、予測可能なコードフローを書く。これこそが、アーキテクチャの深淵を掌握するエンジニアの責務である。
コードが書かれる時、それはすでに実行されている。JITが何を残し、何を捨てるか。その演算の先を読み切るのが、我々の仕事だ。