HHVMのJITと静的型システムの狭間で：デッドコード除去の限界とエンジニアリングの責務
テックリードの私だ。日々のコードレビューで、お前たちが書いたHackのコードを見ていると、「型安全だから安心だ」「HHVMのJITが最適化してくれるからパフォーマンスは落ちない」という過度な信仰を感じることがある。
甘い。
Hackの厳格な静的型システム（Typechecker）と、HHVM（HipHop Virtual Machine）の高度なJITコンパイルパイプラインは、確かに現代のPHP系処理系において最高峰の実行速度をもたらす。しかし、「静的解析で消せないコード」「JITが最適化を諦めざるを得ない構造」というものが確実に存在する。
今回は、HHVMのJITにおけるデッドコード除去（Dead Code Elimination: DCE）の限界メカニズムを解剖し、実務の現場でコンポーネント設計や非同期API連携を行う我々が、どうコードを彫刻すべきかをロジカルに伝授する。
—
1. なぜHHVMのJITは「そのコード」を消せないのか？
HHVMのJITコンパイルは、バイトコード（HBC: HipHop Bytecode）を入力とし、構造的プロファイル情報（PGO: Profile-Guided Optimization）を活用しながらネイティブマシン語（x64 / ARM64）へと変換していく。
JITの最適化フェーズにおいて、デッドコード除去は実行時フットプリントを削減するための重要なパスだ。「到達不可能な分岐」や「誰も参照しないローカル変数」は、当然のように削ぎ落とされる。
しかし、以下の要因が絡むと、JITは手出しができなくなる。
1. 動的なディスパッチとポリモーフィズム
interfaceを多用した依存性注入（DI）や、`classname
2. 非同期境界（AwaitableとAsync Function）のオーバーヘッド
Hackの真骨頂である非同期処理。しかし、`Awaitable`のハンドリングやスケジューリングの裏で生成されるステートマシン構造は、JITにとって複雑な制御フローグラフ（CFG）を生む。結果として、実際にはキャンセルされたり不要になったりした分岐であっても、JITは「安全のために」コードを保持し続ける。
3. リフレクションとメタプログラミングの呪縛
フレームワーク層でありがちな、属性（Attributes）やリフレクションを用いた動的な振る舞いは、JITのインライン展開（Inlining）を阻害する最大の要因だ。
—
2. 現場でやってはいけないアンチパターン
例えば、次のようなコードを見たことはないか？ 「柔軟性を高めたつもり」の典型的なアンチパターンだ。
// 【アンチパターン】JITの最適化を阻害し、デッドコードが残存する構造
namespace App\BadExample;
interface IProcessor {
public function process(string $data): Awaitable
}
class LegacyProcessor implements IProcessor {
public async function process(string $data): Awaitable
// もう誰も使っていないが、インターフェースの実装として残っている
return “LEGACY: “.$data;
}
}
class ModernProcessor implements IProcessor {
public async function process(string $data): Awaitable
return “MODERN: “.$data;
}
}
class Pipeline {
public function __construct(private string $mode) {}
public async function execute(string $data): Awaitable
// $this->mode に応じてインスタンスを切り替えるが、
// JITはこの条件分岐の偏りをPGOが学習するまで両方のルートをネイティブ化する
IProcessor $processor = match($this->mode) {
‘legacy’ => new LegacyProcessor(),
default => new ModernProcessor(),
};
return await $processor->process($data);
}
}
このコードの問題点は、「使われないパス（LegacyProcessor）が存在しているにもかかわらず、HHVMのJITはそれを容易に削れない」という点にある。`match`の分岐先が動的に決まるため、JITは両方のクラスのメソッドを機械語に翻訳し、キャッシュを汚染する。メモリ帯域の無駄遣いであり、キャッシュミスを誘発する元凶だ。
—
3. 堅牢で美しいプロダクションコードの設計パターン
では、どう設計すべきか。
答えは「静的な型システムとコンパイル時定数（Type constants / Generics）を限界まで利用し、分岐そのものを消し去る」ことだ。
以下のコードを見てほしい。これが、Hackの能力を極限まで引き出し、JITに無駄な仕事させないためのプロダクションコードの模範解答だ。
// 【推奨パターン】静的ディスパッチによるJITフレンドリーな設計
namespace App\GoodExample;
/
- 処理戦略を表現するマーカー。
- 実行時ではなく、静的型レベルで処理を完全に分離する。
/
interface IProcessingStrategy {
abstract const string MODE;
public function handle(string $data): string;
}
class ModernStrategy implements IProcessingStrategy {
const string MODE = ‘modern’;
public function handle(string $data): string {
// インライン化（Inlining）されやすいシンプルで純粋な処理
return \strtoupper($data);
}
}
/
- ージェネティクスと静的制約を用いたパイプライン。
- 実行時の条件分岐（if/match）を排除し、JITが完全にデッドコードを排除できるようにする。
/
final class OptimizedPipeline
public function __construct(private Tstrategy $strategy) {}
/
- 非同期処理においても、余計なステートマシンの肥大化を防ぐ。
/
public async function executeAsync(string $data): Awaitable
// この呼び出しは、ジェネティクスによりコンパイル時にターゲットが完全確定する。
// HHVMのJITはダイナミック・ディスパッチのガードを外し、直接呼び出し（Direct Call）へ最適化する。
return $this->strategy->handle($data);
}
}
このコードが優れている理由
1. 静的ディスパッチによるJITのインライン展開
`OptimizedPipeline` はジェネティクス (`Tstrategy`) を用いて具象型をコンパイル時に固定している。これにより、HHVMのJITは仮想メソッドテーブル（vtable）のルックアップを完全にバイパスし、機械語レベルで直接関数呼び出し（Direct Call）に置き換える。結果として、不要なコードはJITの最適化フェーズで綺麗に消え去る。
2. メンテナンシビリティと型の厳格性
レガシーな処理をダラダラとインターフェースの裏に隠すのではなく、戦略ごとにクラスを完全に分離。Typecheckerが不正な組み合わせをビルド時に弾くため、実行時エラーの可能性がゼロになる。
—
テックリードからの総括
HackとHHVMは、お前たちが適当に書いたコードを魔法のように速くしてくれるわけではない。
言語の仕様、型チェッカーの挙動、そしてHHVMのJITが「何を根拠にコードを最適化し、どこで諦めるのか」を脳内にスーパークンプトとしてインストールしている者だけが、真にスケーラブルなWebシステムを構築できる。
コードレビューで「動けばいい」という甘えたセリフを聞くたびに、私はこのアーキテクチャの重みを思い出す。次にコードを書くときは、自分の書いた分岐や依存関係が、JITのネイティブキャッシュにどう影響するかを想像しろ。
妥協のないコードを期待する。