Hackの深淵：JITが「消せない」死に体コードと、その支配術
HackのHHVMアーキテクチャは、世界で最も洗練されたJITコンパイラの一つだ。しかし、君たちが書いたコードが「静的型システムのお墨付き」を得たからといって、HHVMのJITが魔法のように全てを最適化してくれると信じているなら、それは甘い。
今日は、HHVMのJITパイプラインが直面する「デッドコード除去（DCE）の限界」について、コアの視点から紐解く。なぜJITは、君たちが書いた「明らかに不要なコード」を消去できないのか。そして、それを踏まえた上で、我々はどう設計すべきか。
—
1. JITの盲点：静的解析の「保守性」という呪縛
HHVMのJITコンパイラは、実行時プロファイル（PGO: Profile-Guided Optimization）を活用し、ホットパスをネイティブコードへ変換する。だが、JITは「保守的」だ。
「副作用があるかもしれない」と推論されるコードは、たとえ結果が使われていなくても決して削除できない。
特にHackの強力な型システムと組み合わさった以下のパターンは、JITの最適化を阻害する代表格だ。
- 不透明な例外送出: 外部からのインターフェースを介したメソッド呼び出し。
- 不完全な純粋性（Purity）の保証: `<<__Pure>>` 属性が付与されていないが、実際には状態を変更しない関数。
- 動的なディスパッチ: インターフェースやトレイトを介した多態性。
これらは、JITから見れば「いつ何が起きるかわからないブラックボックス」であり、DCEのメスを入れられない聖域となる。
—
2. 実践：デッドコードを排除する設計パターン
「使っていない処理」を消すのではなく、「JITが自信を持って消せるコード」を書く必要がある。以下のリファクタリングを比較してみよう。
アンチパターン：静的解析を惑わせるコード
// 悪い例: JITが副作用を懸念し、評価をスキップできない
public function processData(vec
$result = $this->heavyCompute($data); // 重い計算
if ($this->shouldLog()) {
Logger::info(“Processed”);
}
// $resultが使われていないが、JITは「ここに至るまでの副作用」を消せない
}
改善案：純粋性と明示的な依存関係の分離
JITが最適化しやすいコードは、「状態の変化」と「計算」が明確に分離されているものだ。
<<__Pure>>
function calculateMetrics(vec
// 完全に純粋な関数なら、戻り値が未使用と判定された瞬間、JITは呼び出し自体を破棄できる
return \array_sum($data) 2;
}
public function processData(vec
// コンパイラに「副作用がない」ことを型レベルで伝える
// これにより、最適化フェーズでのインライン展開とDCEが劇的に効く
$val = calculateMetrics($data);
if ($this->shouldLog()) {
Logger::info(“Result: ” . (string)$val);
}
}
—
3. なぜ「純粋性（Purity）」が鍵なのか
Hackにおいて `<<__Pure>>` を関数に付与することは、単なる型チェッカーへのヒントではない。これはJITに対して「この関数内ではグローバル状態の読み書きも、I/Oも発生しない」という究極のコミットメントを表明することを意味する。
JITが「この関数は副作用がない」と確信できれば、その呼び出しを「値そのもの」に置き換える（Constant Folding）だけでなく、呼び出し自体を完全に削除する（Dead Code Elimination）判断が極めて高速かつ安全に行われる。
—
4. プロダクション環境で意識すべき「非同期連携」の罠
Webエンジニアが最も苦しむのが、非同期API連携における「不要な待機」だ。特に `Awaitable` の扱いにおいて、以下の設計はJITの恩恵を殺す。
// 非推奨: 非同期の結果を待機したまま、実は使っていないパターン
$handle = $this->apiCallAsync();
$result = await $handle;
// ここで $result を使わず、後続処理で別のAPIを呼ぶ場合
// JITは「待機」のオーバーヘッドを削除できない
推奨される設計:
// 必要な時までAwaitableを保持し、計算グラフを構築する
$handle = $this->apiCallAsync();
// … 他の処理 …
// 最後にまとめて待機する（非同期の並行性を最大化し、無駄な待機時間を減らす）
$finalResult = await $handle;
—
結論：コードは「機械のために」書く
君たちが書くHackのコードは、人間が読むためのドキュメントであると同時に、HHVMという巨大なエンジンのための「設計図」でもある。
1. `<<__Pure>>` を使い倒せ: 副作用を隔離し、JITに削除の許可を与えろ。
2. 型を絞れ: `mixed` 型や動的な呼び出しは、JITの推論を停止させる最悪の毒だ。
3. プロファイラを信じろ: 自分の直感でDCEを予測するな。`hhvm.jit_profile_on_demand` を活用し、実際にどのコードがネイティブ化されているかを確認せよ。
JITは魔法ではない。しかし、我々が「機械が理解しやすい構造」を与えれば、驚異的なパフォーマンスを叩き出す。コードの美しさは、静的型システムへの適合度だけでなく、JITがどれほど迷わず走り抜けられるかによって決まる。
さあ、君たちのコードベースから「JITの迷路」を排除し、最高速のプロダクション環境を構築しよう。