例外の深淵：HHVM JITが「try-catch」をマシン語へ翻訳する際のアトミックなコスト構造
HHVMのJITエンジンを掌握するということは、単に高レベルなHackコードを書くことではない。HHVMが生成するHHBC（HipHop Bytecode）が、どのようにプロセッサのレジスタへマッピングされ、スタックフレームを破壊し、あるいは再構築するのか。その「呼吸」を理解することだ。
今回は、多くのエンジニアがブラックボックスとして見過ごしている「例外処理のコスト構造」を解剖する。
—
1. 正常系と異常系の非対称性：JITの「コールドパス」戦略
HHVMのJITコンパイラは、コードを「ホットパス（正常系）」と「コールドパス（異常系）」に厳格に分離する。
`try-catch` ブロックを記述した際、JITは単にジャンプ命令を挿入しているのではない。内部的には Landing Pad（着地点） と呼ばれるメタデータテーブルを生成し、例外発生時にCPUの命令ポインタ（RIP）がどこへ飛ぶべきかを制御している。
正常系におけるゼロコストの幻想
`try` ブロック内に例外が投げられない場合、HHVMの生成するマシン語には、ほとんどオーバーヘッドは存在しない。これは、スタックを巻き戻すためのメタデータを実行時テーブルとして外部化しているからだ。しかし、この「メタデータ参照」というコストはゼロではない。関数呼び出しのたびに、その関数が例外を投げる可能性があるかどうかの「境界」がプロセッサの分岐予測に微妙なノイズを与える。
2. スタック・アンワインディングの物理的コスト
例外が `throw` された瞬間、CPUは何を行っているのか。
1. コンテキストの強制退避: 現在のスタックポインタ（RSP）とベースポインタ（RBP）を保持したまま、ランタイムの例外ハンドラへ制御を渡す。
2. メタデータの探索: `__ex_table` 領域を逆引きし、現在のRIPに対応するハンドラが存在するかを確認する。
3. フレームの巻き戻し: 呼び出し元（Caller）のスタックフレームを復元する。この際、RAII（Hackにおいては `using` 文）によって確保されたリソースのクリーンアップが自動的に呼び出される。
このプロセスは、通常の関数呼び出し（`call`/`ret`）よりも数桁重い。なぜなら、プロセッサのパイプラインを完全にフラッシュし、投機的実行をすべて破棄しなければならないからだ。
—
3. 実践：JITを意識したコード・パターン
以下のコードを例に、JITの挙動を脳内トレースしてみよう。
// パフォーマンスを重視するループ内での例外処理 もし、このループ内で頻繁に例外が発生するような設計であれば、それはアーキテクチャの敗北だ。HHVMのJITは、`catch` ブロック内を「極めて低頻度な実行コード」とみなし、メインのホットパスから物理的に遠いメモリ領域（Cold Section）に配置する。 これにより、キャッシュミス（I-Cache Miss）が強制的に発生する。例外を「制御フロー」として使うことは、CPUのプリフェッチャーに対する「テロ行為」に等しい。 — HHVMの深淵を知るエンジニアは、以下の原則を守る。 HHVMのJITにとって、`try-catch` はコードを安全に保つための「保険」であるが、保険料（パフォーマンスコスト）は決して安くない。 あなたが書く一文字のコードが、CPUのパイプラインを止めるのか、それとも淀みなく通過するのか。その境界線にこそ、伝説的なシステムアーキテクトが追い求める「純粋な速度」が存在する。 次は、HHVMの `TypeSpec` がどのようにJITの特化を加速させているか、その静的解析の核心に触れることにしよう。真のエンジニアであれば、機械語が語る真実を恐れてはならない。
function process_data(vec
foreach ($data as $val) {
try {
// 正常系のみを通す設計にする
if ($val < 0) throw new InvalidArgumentException();
// ... 高速な演算処理 ...
} catch (InvalidArgumentException $e) {
// 例外発生時は極めて稀（または制御フローの一部）であるべき
handle_error($val);
}
}
}
このコードにおける「極限の知見」
4. パフォーマンスを最適化するための「防御的実装」
結びに代えて