HHVMのJITコンパイルと静的型システムの限界：静的解析で消せない「亡霊コード」を如何にして葬るか
HHVM（HipHop Virtual Machine）のアーキテクチャ、そしてHack言語の厳格な静的型システム（Typechecker）の深淵を覗いたことがある者ならば、コンパイル時と実行時の境界線がいかに曖昧であるかを痛感しているはずだ。
Hackは、PHPの動的な側面を削ぎ落とし、厳格な型安全性と非同期処理（Async）をネイティブに近い速度で実行するために設計された。我々はTypecheckerによってコードの整合性を担保し、HHVMの多段階JITコンパイラ（TC : Translation Cache）によってそれを超高速なマシン語へと昇華させている。
しかし、どれほど高度な静的解析とJITの最適化パスを重ねようとも、「実行時まで消去できないデッドコード（亡霊コード）」は確実に存在する。
今回は、HHVMのJITパイプラインにおけるデッドコード除去（Dead Code Elimination: DCE）の限界メカニズムを解剖し、開発者が無意識に生み出す「最適化阻害要因」をどう排除すべきか、その極限の知見を共有しよう。
—
1. HHVMのJITパイプラインとDCEの現在地
HHVMの実行モデルは、単なるバイトコードインタープリタではない。
初期のバイトコード実行（Interp）から始まり、プロファイリング情報を収集するプロファイル実行（Prof）、そして最終的にnative machine codeを生成するJIT（TC）へと移行する。
JITの最適化フェーズにおいて、DCEは非常に重要な役割を果たす。基本ブロック（Basic Block）単位、あるいはSSA（Static Single Assignment）形式に変換されたIR（Intermediate Representation）上で、使用されない定義（Dead Definitions）や、到達不能な分岐（Unreachable Branches）は容赦なく排除されるはずだ。
しかし、HHVMのDCEは以下の構造的制約により、完全にコードベースをクリーンに保つことができない。
1. 動的なディスパッチとリフレクションの残滓
2. Hackのジェネリクス（Generics）における型消去（Type Erasure）とリージョン制約
3. 副作用（Side Effects）の追跡不可能性
4. TC（Translation Cache）の有効期限とインバリデーションのコスト
特に、シニアエンジニアが見落としがちなのは「静的解析では無駄に見えないが、JITの視点では最適化を阻害する構造」である。
—
2. 静的解析で消せない「3つの亡霊コード」パターン
実際のHackコード片を用いて、JITがなぜそれを排除できないのか、その内部メカニズムを紐解こう。
パターンA: 複雑なジェネリクスとファクトリーパターンの罠
Hackのジェネリクスは非常に強力だが、実行時における具象型の扱いは時にJITのインライン化（Inlining）を阻害する。
// strict
namespace HackArchitectures\DCE;
interface IProcessor {
public function execute(): void;
}
class FastProcessor implements IProcessor {
public function execute(): void {
// 高速パス
}
}
class HeavyProcessor implements IProcessor {
public function execute(): void {
// 巨大かつ稀にしか使われない処理
}
}
class ProcessorFactory {
// 開発者は「どちらか一方しか使わない」と知っているが、
// 静的解析およびJITのプロファイル段階では両方の分岐が生存し続ける
public static function create(bool $is_heavy): IProcessor {
if ($is_heavy) {
return new HeavyProcessor();
}
return new FastProcessor();
}
}
JITの視点と限界
このコードにおいて、`HeavyProcessor` が長期間呼び出されない場合でも、JITはこれらを即座にデッドコードとして消去することはできない。
なぜなら、`ProcessorFactory::create` は実行時引数 `$is_heavy` に依存しており、TC内ではポリモーフィックな呼び出しサイト（Polymorphic Call Site）として扱われるからだ。
JITが単態化（Monomorphization）を行うには十分なプロファイルサンプルが必要であり、サンプルが不足している間は、使われていない `HeavyProcessor` のクラス定義やメソッド本体のバイトコードがメモリ空間（TC）を専有し続ける。
—
パターンB: 形状（Shape）と不変性（Immutability）の幻想
Hackの `shape` や `dict` は非常に高速だが、動的なキーアクセスや条件分岐が絡むと、DCEのスコープ外へと追いやられる。
type TConfig = shape(
‘enable_feature_a’ => bool,
‘enable_feature_b’ => bool,
);
class FeatureExecutor {
public function run(TConfig $config): void {
if ($config[‘enable_feature_a’]) {
$this->executeA();
}
// 仮に ‘enable_feature_b’ が全環境で一律に false であったとしても、
// $config が外部から注入されるデータ構造である場合、
// JITはこのブロックを「デッドコード」と判定できない。
if ($config[‘enable_feature_b’]) {
$this->executeB(); // 永遠に実行されない亡霊コード
}
}
private function executeA(): void {}
private function executeB(): void {
// 巨大なレガシー処理（本当は消したい）
}
}
メモリ最適化上のペナルティ
`executeB` メソッド自体はバイトコードとしてロードされ、HHVMのメソッドテーブルに常駐する。JITは「到達可能性（Reachability）」をグローバルではなく関数/トレース単位で評価するため、親メソッド `run` がホットパスである限り、死んだ分岐を含むコード全体がTCの翻訳対象となり得る。結果として、I-cache（命令キャッシュ）のフットプリントを無駄に圧迫する。
—
3. 限界を突破する：極限のアーキテクチャ設計
この「消せないコード」をランタイムレベル、あるいは設計レベルで完全に排除するためのアプローチを提示する。
1. コンパイル時定数（`typeconst` / `Value List`）の強制
実行時判定ではなく、定数（Constant）やマクロ的なアプローチを用いて、JITの定数畳み込み（Constant Folding）を強制的に発動させる。
class RuntimeConfig {
// 変更不可の静的フラグとして定義
const bool ENABLE_FEATURE_B = false;
}
class OptimizedExecutor {
public function run(): void {
$this->executeA();
// HackのTypecheckerおよびJITは、これがコンパイル時定数であることを検知すると、
// 条件分岐そのものを評価せず、ifブロックをごっそり削除（Dead Branch Elimination）する。
if (RuntimeConfig::ENABLE_FEATURE_B) {
$this->executeB(); // バイナリレベルで完全に消滅する
}
}
private function executeA(): void {}
private function executeB(): void {}
}
2. リージョン分離とアグレッシブなクラス構造の分割
巨大なインターフェイスや継承ツリーを避け、機能ごとに完全に独立したモジュール（命名空間およびファイル単位）に分割する。HHVMのローダーは遅延ロード（Lazy Loading）を行うため、使われていないクラスはバイトコードキャッシュ（RepoAuthoritativeモード時のヒット率向上）の汚染を防ぐことができる。
—
4. チーフアーキテクトからの提言
HackとHHVMは、現代のPHPエコシステムにおいて類まれな高速性と堅牢性を提供してくれる。しかし、「型がついているから安全」「JITが勝手に最適化してくれるだろう」という甘えは、大規模システムにおいて確実にI-cacheミスやTCの肥大化という形でしっぺがえしを受ける。
真に洗練されたシステムとは、書いたコードの量ではなく、「ランタイムの視界からどれだけノイズを消し去ったか」によってのみ測られる。
デッドコードは単なるゴミではない。それはJITの推論を惑わせ、CPUキャッシュを汚染する「見えない敵」なのだ。
コードを書くときは常に想像せよ。その分岐は、そのクラスは、本当にJITのバイナリ生成フェーズにおいて生存する価値があるのかを。