HHVMの深淵：JITが「見えない」死をどう殺し、我々はどう抗うか
Hackの静的型システム（Hack Typechecker: HHAST/HHVM）は、開発中に「型」という名の盾で我々を守ってくれる。しかし、その先のHHVM（HipHop Virtual Machine）におけるJITコンパイルの世界は、型安全とは別の次元――「実行時コスト」という冷徹な現実が支配する領域だ。
今日は、JITコンパイルにおける「デッドコード除去（DCE: Dead Code Elimination）」の限界について、アーキテクトの視点から切り込む。なぜ「書いたはずのコード」がJITを鈍らせるのか。そして、それを排除し、最高速のプロダクションコードを書くための作法を伝授する。
—
1. JITの盲点：静的解析と動的実行の乖離
HHVMのJITエンジンは、HIR（High-level Intermediate Representation）を生成し、何度もパスを回して最適化を行う。しかし、「静的解析で到達不能と証明できないコード」は、たとえ一度も実行されなくても、機械語としてメモリにロードされる。
なぜデッドコードが消えないのか？
- 動的ディスパッチ: `interface`や`trait`を介した呼び出しは、JITがプロファイリングを行うまで「どの具象クラスが呼ばれるか」を確定できない。
- リフレクションと外部バインディング: Hackが提供する強力なメタプログラミング機能は、コンパイル時に「どこから呼ばれるか」のパスを曖昧にする。
- 過剰な抽象化: 汎用性を求めすぎた関数は、JITの「インライン展開（Inlining）」の限界を突破させ、結果として最適化のスコープから外れる。
—
2. 「JITフレンドリー」なコード設計：アンチパターンを排除する
実務でよく見る「保守性は高いがJITを殺すコード」を、いかにして最適化するか。
【NGパターン：過剰なインターフェースの抽象化】
interface Processor { public function handle(): void; }
// これを数百回ループで呼び出すと、JITは「どのhandleを呼ぶべきか」の分岐予測に失敗し続ける
public function process(Vector
foreach ($items as $item) {
$item->handle();
}
}
【推奨：JITを解放する具象化とシール】
HHVMのJITを最大化する鍵は、「型を限定し、インライン展開を促進する」ことだ。`sealed`インターフェースや`final`クラスを多用し、JITが呼び出し先を静的に特定できるようにする。
// 具象を制限することで、JITは呼び出し先の機械語をスタック上に展開できる
<<__Sealed(TypeA::class, TypeB::class)>>
interface Processor { public function handle(): void; }
final class TypeA implements Processor {
public function handle(): void { / 処理 / }
}
// JITは「TypeAかTypeBしかない」と認識し、分岐予測を最適化する
public function process(Vector
foreach ($items as $item) {
// ここでインライン展開が成功し、関数呼び出しオーバーヘッドがゼロになる
$item->handle();
}
}
—
3. 実務で即効性のある最適化：非同期API連携の設計
非同期処理における「無駄な待機とメモリ確保」は、JIT以前にHHVMのタスク管理を圧迫する。特に`Awaitable`の連鎖は、生成されるオブジェクトが多すぎるとJITのキャッシュを汚染する。
美しいプロダクションコード例：バッチ処理の最適化
個別にAPIを叩くのではなく、型安全なデータ構造で一括処理する。
final class ApiBatchProcessor {
/
- 個別にAwaitするのではなく、Vecを生成して一気に処理する
- JITはループ内の型が固定されていることを検知し、SIMD命令に近い最適化を試みる
/
public async function processBatch(vec
$tasks = vec[];
foreach ($ids as $id) {
$tasks[] = $this->callExternalApi($id);
}
// Awaitableの集合を一気に処理することで、HHVMのスケジューラ効率が最大化される
await Vec\map_async($tasks, async $t ==> await $t);
}
private async function callExternalApi(int $id): Awaitable
// 外部連携の際も、返り値の型を厳格にすることでJITの推論を助ける
return “result_”.$id;
}
}
—
4. アーキテクトからの提言：計測なき最適化は罪
Hackの強みは「厳格な型」にあるが、型安全であることと、実行速度が速いことは別問題だ。
1. `<<__Inline>>`の使い所: JITコンパイラに「ここをインライン展開せよ」と明示的に指示を送る属性（`__Inline`）は強力だが、多用は禁物だ。バイナリサイズが肥大化し、逆にキャッシュミスを誘発する。
2. プロファイリング: `hhvm.jit.profile_log` を活用し、実際のプロダクション環境で「どこでJITが再コンパイルを繰り返しているか（JIT Re-compilation）」を可視化せよ。
まとめ：
「デッドコードを消そう」と腐心するよりも、「JITが最適化しやすい道筋を作る」こと。それが、Hackを掌握したエンジニアの戦い方だ。型によって静的解析の範囲を広げ、`final`や`sealed`で動的挙動の不確実性を殺す。この設計哲学こそが、HHVMという強大なエンジンを飼い慣らす唯一の方法である。
次にコードを書くとき、自問してほしい。
「このコードの呼び出し先を、JITは静的に特定できるか？」と。