静的解析の極北：HHVM型チェッカーがデッドコードを「殺す」論理
Hackにおける厳格モード（Strict Mode）は、単なる「バグの早期発見ツール」ではない。それは、ソースコードを数学的に厳密なグラフへと変換し、実行前にすべての論理的破綻を排する「静的コンパイルの頭脳」である。
その中でも、デッドコード（到達不能コード / Unreachable Code）の検知は、型チェッカー（`hh_client`/`hh_server`）とHHVM（HipHop Virtual Machine）のJITコンパイルが高度に連携する、最もエキサイティングな領域の一つだ。
多くの開発者は、デッドコードを「単に実行されない無駄なコード」程度に考えている。しかし、HHVMのコアアーキテクチャにおいて、デッドコードの存在は型推論の汚染、JITコンパイル時のトレース汚染、そして不要なレジスタアロケーションによるメモリ・CPU効率の低下を招く致命的なノイズに他ならない。
本稿では、Hackの型チェッカーがどのようにプログラムの実行パスを解析し、デッドコードを特定・排除しているのか、その静的解析アルゴリズムの深淵と、HHVMランタイムへの影響を解き明かす。
—
1. 静的解析の基盤：コントロールフローグラフ（CFG）とボトムタイプ `nothing`
Hackの型チェッカー（OCamlで記述された超高速静的解析エンジン）は、ソースコードを抽象構文木（AST）に変換した後、即座にコントロールフローグラフ（CFG: Control Flow Graph）を構築する。
CFGにおける最小単位は基本ブロック（Basic Block）である。基本ブロックは、「途中に分岐（ジャンプ）がなく、一方向にのみ実行される命令のシーケンス」だ。
[ Basic Block A ]
/ \
/ (true) \ (false)
v v
[ Basic Block B ] [ Basic Block C ]
Hackの型チェッカーは、このCFG上を変数に割り当てられた型情報（環境：Environment）が流れるフローセンシティブ（流れに依存する）解析を行う。
ボトムタイプ `nothing` の数学的意味
デッドコード解析において極めて重要なのが、Hackの型システムにおける最下位の型（Bottom Type）である`nothing`だ。
- `mixed`型が「何でもあり得る」トップタイプ（Top Type）であるのに対し、`nothing`型は「いかなる値も持ち得ない」ことを示す。
- ある実行パスにおいて、変数の型が`nothing`に収束した場合、あるいはCFGのあるエッジにおける事後条件（Postcondition）が「空集合（$\emptyset$）」となった場合、その基本ブロックへの到達は物理的・論理的に不可能であると判定される。
これが、Hackにおけるデッドコード検知の数学的帰結である。
—
2. 型チェッカーの到達不能コード検知アルゴリズム
`hh_client`がデッドコードを特定するアプローチは、主に以下の3つのレイヤで駆動する。
① 型の絞り込み（Type Refinement）と矛盾の検出
最も一般的なデッドコードは、静的な条件分岐において「絶対に真になり得ない」論理的矛盾が生じた瞬間に発生する。
function analyze_value(mixed $val): void {
if ($val is int && $val is string) {
// このブロックはデッドコード
echo “This is impossible”;
}
}
このコードに対し、型チェッカーは以下のステップを実行する。
1. `$val is int` の評価により、真のパスにおける `$val` の型を `int` に絞り込む（Refinement）。
2. 続く内側の条件 `$val is string` を評価する際、現在の環境（Environment）における `$val` の型 `int` と `string` の共通部分（Intersection）を計算する。
3. $\text{int} \cap \text{string} = \emptyset$（空集合）であるため、このパスにおける `$val` の型は `nothing` となる。
4. 型チェッカーは「型が `nothing` である変数が存在する実行パス」、すなわちこの基本ブロックを到達不能（Unreachable）とマークし、エラー `Unreachable code (Naming[2013])` または `Invalid type` を投げる。
② `noreturn` 型によるCFGのエッジ切断
Hackには、呼び出し元に制御を戻さない関数を示す `noreturn` 型が存在する。
- `HH\invariant_violation()`
- `exit()` / `die()`
- 例外の無条件スロー
CFGにおいて、`noreturn` を戻り値とする関数呼び出しを含むノードに到達した場合、型チェッカーはその基本ブロックから後続のブロックへ伸びるアウトエッジ（出力枝）をすべて切断する。
[ Block A: Call invariant_violation() ]
|
(エッジが切断される)
x
[ Block B: 後続の処理 ] <-- ここがデッドコードになる
③ ジェネリクスの不変性（Invariance）と幽霊型による静的境界
より高度なメタプログラミングにおいて、ジェネリクスの型パラメータの不一致からデッドコードを静的に導き出す。
例えば、共変性（Covariance: `+T`）や反変性（Contravariance: `-T`）の制約下において、満たし得ない型境界（Type Bound）が交差した瞬間、型チェッカーはCFG上の該当ブランチを即座に「死」と判定する。
—
3. HHVMへの架け橋：JITとメモリの極限最適化
なぜここまで厳密にデッドコードを排除するのか？それは、Hackの実行エンジンであるHHVMのJITコンパイラ（Translおよび低レイヤ中間表現 VASM）の設計思想に直結している。
[ Hack Source Code ]
| (hh_client: 静的解析・デッドコード排除)
[ HackC (Compiler) ]
|
[ HHVM Bytecode (HHBC) ]
| (HHVM JIT: Transl / VASM)
[ Optimized Machine Code ]
HHBC（HHVM Bytecode）の生成抑制
デッドコードと判定された領域は、コンパイラ（`hackc`）によってHHBC（HHVM Bytecode）に変換される段階で、最初から生成をスキップされるか、最小限のトラップ命令に置き換えられる。これにより、コンパイル後のバイナリサイズ（`.hhas`）が劇的に削減される。
JITのトレース・キャッシュ（Tracelet）の汚染防止
HHVMは、実行時のプロファイル情報を基に、頻繁に実行されるコードパス（Tracelet）をコンパイルしてネイティブ機械語（x86_64 / AArch64）にする。
もしデッドコードがバイトコードレベルで残っていた場合、JITコンパイラは「実行される可能性が極めて低いパス」に対してもコンパイルリソース（レジスタ割り当て、型プロファイリングのメタデータ確保）を割かざるを得なくなる。
静的解析でデッドコードを100%排除することで、HHVMのJITは真に実行されるパスのみにマシンリソースを集中させ、インストラクションキャッシュ（I-Cache）のヒット率を極限まで高めることができるのだ。
—
4. 極限のHackコード例：CFGの破壊とデッドコードの完全コントロール
以下に、型チェッカーのフロー解析とデッドコード検知の挙動を完全に脳内トレースするための、極限まで研ぎ澄まされたコード例を示す。
ここでは、代数データ型（ADT）を模した抽象クラス、`noreturn`によるエッジ切断、および`nothing`型の伝播を組み合わせ、型チェッカーがどのようにデッドコードを「視認」しているかを明示する。
<<__Entrypoint>>
async function main(): Awaitable
$processor = new FlowProcessor();
// シナリオ1: 正常系
$processor->execute(new SuccessResult(“Data processed successfully.”));
// シナリオ2: 異常系（noreturnによるCFGの分断）
// この呼び出しの後、型チェッカーは後続のコードが「実行不可能」であることを検知する
$processor->terminate_with_error(“Fatal Engine Failure”);
/ HH_FIXME[4101] もしくは型チェッカーによるエラー出力を観察するため、あえて以下を記述 /
// 以下のコードは、hh_clientによって「到達不能」として弾かれる。
// なぜなら、上の行の `terminate_with_error` が `noreturn` を返すため、
// CFGのエッジがここで途切れているからだ。
$unreachable_var = 42;
echo “This line will never be executed or compiled: {$unreachable_var}\n”;
}
abstract class OperationResult {}
final class SuccessResult extends OperationResult {
public function __construct(public string $payload) {}
}
final class FailureResult extends OperationResult {
public function __construct(public int $code) {}
}
final class FlowProcessor {
/
- noreturn型を返すメソッド。
- このメソッドが呼ばれた時点で、呼び出し元のCFGのこのノードから先へのエッジは消滅する。
/
public function terminate_with_error(string $reason): noreturn {
// ログ出力（HHVMの低レイヤシステムコールを模倣）
HH\autoload_is_enabled();
throw new \RuntimeException(“Execution Terminated: “.$reason);
}
/
- フローセンシティブな型推論によるデッドコード検知のデモ
/
public function execute(OperationResult $result): void {
if ($result is SuccessResult) {
// $result の型は SuccessResult にRefineされている
$this->logSuccess($result->payload);
} else if ($result is FailureResult) {
// $result の型は FailureResult にRefineされている
$this->logFailure($result->code);
} else {
// OperationResult のサブクラスは SuccessResult と FailureResult のみであるため、
// この `else` ブロックに到達した時点で、$result の型は `nothing`（空集合）となる。
//
// 型チェッカーは、このブロックの内部を「デッドコード」と判定する。
// 仮にここで $result のメソッドを呼ぼうとすると、型チェッカーは厳格にエラーを吐く。
/ HH_FIXME[4072] 到達不能コード内での無効な型操作 /
$result->nonExistentMethod();
}
}
private function logSuccess(string $msg): void {
echo “SUCCESS: {$msg}\n”;
}
private function logFailure(int $code): void {
echo “FAILURE: Error Code {$code}\n”;
}
}
このコードにおける `hh_client` の脳内ログ
1. `main()` 内の `terminate_with_error` のシグネチャを走査。
- 戻り値が `noreturn` であることを確認。
2. `main()` のCFGを更新：
- `$processor->terminate_with_error(…)` のノードを「ターミナルノード（終端）」に設定。
- 次の基本ブロック（`$unreachable_var = 42;`）への遷移確率を $0$ に設定。
3. エラー判定：
- `$unreachable_var = 42;` に対し、`Unreachable code (Naming[2013])` を出力。
4. `execute()` 内の `else` ブロックの走査：
- `$result` が `SuccessResult` でも `FailureResult` でもない状態を計算。
- 型制約の共通部分が $\emptyset$ になったため、`$result` の型を `nothing` に決定。
- `nothing` に対するあらゆるメンバアクセス（`nonExistentMethod`）はコンパイルエラー（またはデッドコード警告）となる。
—
5. アーキテクトの視点：静的厳格性とランタイムの調和
我々がシステムを限界まで高速化しようとする時、ボトルネックとなるのは常に「不確実性」である。
動的言語が遅いのは、実行時まで変数の型も、次に実行されるコードの場所も確定しないからだ。HHVMは、Hackという「静的型システム」という強力な盾を得ることで、実行前に不確実性を極限まで削ぎ落とすことができる。
型チェッカーがデッドコードを冷徹に切り捨てるアルゴリズムは、単に開発者にバグを知らせるためのものではない。それは、HHVMのJITコンパイラに対し、「このパスは絶対に考慮しなくてよい」という鉄の保証（アサーション）を与える儀式なのだ。
デッドコードの排除は、ゼロコスト抽象化（Zero-cost Abstraction）を実現し、HHVMが真に高速なネイティブコードをジェネレートするための、最も美しく、最も冷徹な最適化フェーズなのである。