HHVMの深淵：JITが「見捨てた」デッドコードを、我々はどう屠るべきか
Hackの静的型システムを信頼し、`hh_client`が何も言わないことに安心している諸君。君たちの書いたそのコード、本当に「実行時」も綺麗だと言い切れるか？
HHVMのJITコンパイラは世界屈指の知能を持っている。しかし、奴らにも「見えない壁」がある。静的解析の限界と、JITがランタイムで直面する「消せない残骸」の正体を暴こう。
1. JITの限界：なぜ「静的解析」は空回りするのか
HHVMのJITエンジンは、プロファイル駆動型最適化（PGO）を駆使し、ホットパスをネイティブコードに変換する。しかし、以下の状況ではJITの最適化は無力化する。
- 動的なインターフェースの解決: `interface`を介した多態性が極端に高い場合、インライン展開が阻害される。
- 不透明な依存関係: `Shapes`や`dict`などの疎なデータ構造を深くネストさせた場合、型推論の境界が曖昧になり、JITは「万が一」のために分岐を温存せざるを得ない。
- ガード条件の過剰生成: 実行時に型を確認する`is`演算子や`as`キャストを多用すると、JITはガード命令を大量に生成し、かえって命令キャッシュ（I-Cache）を汚染する。
JITにとって、静的に「到達不能」と証明できないコードは、たとえ99.9%実行されなくても「生きている」とみなされる。この「死に損ないのコード」が、プロセッサの予測分岐を狂わせるのだ。
2. 現場で使える「デッドコードを生まない」設計パターン
「後で使うかもしれない」という迷いは、アーキテクチャの癌だ。JITを味方につけるための、最も美しいパターンを伝授しよう。
パターンA：`Shapes`の徹底的な具象化とシール（Sealing）
不透明な`dict`の受け渡しは、JITの天敵だ。`Shape`を用いて型を固定し、可能な限り`final`クラスでカプセル化する。
namespace App\Core;
// 曖昧なdictを排除し、型安全なShapeを定義する
type TUserPayload = shape(
‘id’ => int,
‘role’ => string,
);
final class UserProcessor {
// 静的型システムが解析可能な領域を最大化する
public function process(TUserPayload $payload): void {
// 実行時に型チェックが不要なため、JITはガードを生成せず、
// 直結のネイティブコードを生成できる
$this->handle($payload[‘id’]);
}
private function handle(int $id): void {
// 処理の末端
}
}
パターンB：不要な分岐の「早期確定」
非同期API連携などでありがちな「レスポンスの形が複数ある」状況。`match`式を活用して、コンパイル時にパターンを網羅させることで、JITは不要な分岐をコンパイルアウトできる。
enum ApiStatus: string {
Success = ‘ok’;
Error = ‘fail’;
}
function handleResponse(mixed $raw): void {
// matchは網羅性を強制するため、実行時の「想定外の分岐」を削除できる
$status = ApiStatus::coerce($raw[‘status’] ?? null);
match ($status) {
ApiStatus::Success => $this->onSuccess($raw[‘data’]),
ApiStatus::Error => $this->onError($raw[‘code’]),
// nullなどの「想定外」をここで排除することで、
// JITは以降のコードから「nullチェック」を完全除去する
null => throw new InvalidArgumentException(‘Invalid State’),
};
}
3. なぜ「そのコード」は非効率なのか：テクニカルリードの視点
コードレビューの現場で、私が必ず指摘するのは以下の3点だ。
1. 「念のためのチェック」の積み重ね: `if ($obj is ClassA) { … }` をホットパスで繰り返すな。ポリモーフィズムは抽象クラスやインターフェースのメソッド呼び出し（V-Table参照）に任せろ。JITはメソッドのインライン化が得意だが、`is`演算子の連打は処理を停止させる。
2. クロージャの過剰利用: 非同期処理でクロージャを多用すると、HHVMはそれを「オブジェクト」としてヒープに割り当てる。これはGC（ガベージコレクション）の負荷を増大させる。単純な処理は名前付きメソッドに切り出し、JITがインライン化の判断を下しやすくしろ。
3. 不必要な非同期境界: 全てを`Awaitable`で包むな。同期的に処理可能なものを無理に非同期化すると、ステートマシンの生成コストがJITの最適化を阻害する。
結論：JITは君の「意志」をコード化する
JITコンパイラは、君が書いたコードの「意図」を読み取ろうと必死だ。君が曖昧な型、過剰な分岐、不透明なデータ構造を書けば、JITは「安全策」を取らざるを得ない。それはつまり、パフォーマンスの低下という形で君に跳ね返ってくる。
「静的型システムで殺せないコードは、人間が設計で殺せ」。
これが、Hackのパフォーマンスを極限まで引き出すための唯一の道だ。この知見を持って、明日のコードを見直してほしい。君たちの書くHackコードが、HHVMの上で軽やかに舞うことを期待している。