やあ。Hackの深淵へようこそ。私はHHVMの心臓部を長年見つめてきたエンジニアだ。
君たちは日々、Hackの堅牢な静的型システムに守られ、快適にコードを書いていることだろう。だが、HHVMのJIT（Just-In-Time）コンパイラが「なぜこのコードを消してくれないのか？」と歯痒い思いをしたことはないかな？
今日は、静的解析とJITの境界線――「デッドコード除去（DCE）の限界」について、現場の知見を共有しよう。ここを理解すれば、君の書くコードは一段階上の「軽量かつ高速な機械語」へと昇華されるはずだ。
—
1. JITの限界：なぜ「静的解析」だけでは足りないのか
まず、HHVMのJITは魔法ではないということを理解する必要がある。JITは「実行時のプロファイル」を元に最適化をかけるが、コンパイラには「未知の呼び出し」という巨大な壁が存在する。
例えば、クラスのメソッドが `public` であったり、インターフェースを実装していたりする場合、JITは「将来的に他のクラスから継承・オーバーライドされるかもしれない」という可能性を捨てきれない。
「消せないコード」の正体
interface IWorker { public function doWork(): void; }
class DataProcessor {
// コンパイラは、このメソッドが後から動的に拡張される可能性を考慮し、
// 完全にインライン化や削除をすることが難しい場合がある
public function process(IWorker $worker): void {
$worker->doWork();
}
}
この `process` メソッド内での `$worker->doWork()` は、静的解析の時点では「どのコードが実際に実行されるか」を100%特定できない。これが、JITが大胆な最適化を躊躇する理由の一つだ。
—
2. 現場で陥りやすい「最適化を阻害するパターン」
初学者が書きがちな、JITに嫌われるコードの代表例を見てみよう。
アンチパターン：過度な柔軟性による「デッドコードの居座り」
class HeavyObject {
public function __construct(private bool $isFeatureEnabled) {}
public function execute(): void {
if (!$this->isFeatureEnabled) {
return; // ここで早期リターン
}
// この先にある重い計算処理が、コンパイラから見て
// 「完全に死んでいるコード」だと断定しづらい構造に陥ることがある
$this->complexCalculation();
}
}
このコード、実は `$isFeatureEnabled` がインスタンスごとに異なる場合、JITは「この条件分岐は動的である」と判断し、`complexCalculation` を削除する最適化を諦めることが多い。結果、実行時に不要な分岐コストが乗り続けることになる。
—
3. コードを「削ぎ落とす」ための極意
では、どうすればJITに「これは消していいんだよ」と教えてやれるのか？ 鍵は「静的な閉域」を作ることだ。
解決策：final と sealed の積極利用
Hackが提供する強力な型システム機能を使おう。`final` や `sealed` を使うことで、コンパイラに対して「これ以上継承・変更されることはない」という強い保証を与えるんだ。
// sealed を使うことで、サブクラスを列挙し、推論範囲を限定する
sealed interface IAction {
case class Login();
case class Logout();
}
final class Executor {
public function run(IAction $action): void {
// コンパイラは「IActionの全ケース」を知っているため、
// 未使用のコードパスがあれば、迷わず除去してくれる
switch ($action) {
case IAction::Login(): / … / break;
case IAction::Logout(): / … / break;
}
}
}
なぜこれが効くのか？
`sealed` を使うと、コンパイラは「このインターフェースを実装しているのはこの2つだけだ」と確信できる。すると、実行時のメソッド探索（vtableルックアップ）をスキップし、直接的な呼び出しへと変換できるんだ。これが、JITにとっての「最適化の引き金」になる。
—
4. チーフアーキテクトからのアドバイス
Hackでコードを書く際、以下の3点を意識するだけで、生成される機械語の質は劇的に変わる。
1. 「オープン」をデフォルトにしない: クラスやメソッドには、可能な限り `final` を付ける癖をつけよう。拡張性が必要なときだけ開放する。これがHHVMを最大効率で回すためのマナーだ。
2. 型を絞り込む: `mixed` を多用するのは、JITに目隠しをしているのと同じだ。可能な限り具体的な型を定義し、推論エンジンにヒントを与えよう。
3. 不必要な分岐は「コンパイル時」に解決する: 実行時の `if` 文を減らし、`Type-Refinement` やパターンマッチングを活用して、コードの論理的な枝をコンパイラにハッキリと認識させること。
—
まとめ：Hackを掌握するということ
Hackの静的型システムは、単なるエラーチェックツールじゃない。JITコンパイラに対して「どのコードが不要か」を伝えるための、究極のコミュニケーション言語なんだ。
「動けばいい」コードから「最適化されるために書かれた」コードへ。その意識の切り替えができたとき、君はもうHackを真に理解したと言える。
ここをクリアすれば、君のアプリケーションは驚くほど軽快に動くようになるはずだ。もし壁にぶつかったら、いつでも戻っておいで。Hackの深淵は、いつでも君を歓迎するよ。