HHVMの深淵：JITが生成する「例外」のコストとスタックアンワインディングの物理学
Hackのチーフアーキテクトとして、多くのエンジニアが「なんとなく」書いている`try-catch`が、HHVMのJITエンジンにおいてどのような物理的足跡を残しているのかを説こう。
多くの言語仕様書は「例外はコストがかかる」と短く記すが、我々ランタイムエンジニアにとって、それは「命令パイプラインの断裂」と「メモリ階層への過酷な負荷」を意味する。HHVMが動的型付けの柔軟性と静的型の安全性を両立させながら、なぜこれほどまでに高速なのか。その秘密は、例外処理という「異常系」を、いかにして「通常の実行パス」から物理的に分離し、JITが生成するマシンコードに埋め込むかにある。
—
1. JITにおける「正常系」と「異常系」の物理的分離
HHVMのJIT（Transitive JIT / TC）は、例外が発生しないことを前提に、ホットパスを極限まで最適化する。ここで重要なのは、「例外が発生する可能性」そのものが、投機的実行（Speculative Execution）の障壁になるという事実だ。
隠された構造：Landing Pad
`try-catch`ブロックを記述すると、JITは単なるジャンプ命令を生成するのではない。LLVM IR（あるいはHHVM独自のIR）レベルで、例外発生時の脱出先である「Landing Pad」を生成する。
// 概念的なJIT生成コードの配置
+———————–+
| Hot Code Path (JIT) | <-- レジスタ最適化がフル稼働
+-----------------------+
| ... (branch) |
+-----------------------+
| Cold Region (Landing | <-- ここが重要。物理的に離れたメモリ領域
| Pad & Unwind Logic) | I-Cache汚染を最小化する
+-----------------------+
この分離により、正常な実行時は`Landing Pad`のコードがCPUのI-Cache（命令キャッシュ）を汚染することがない。JITは「例外が発生しない場合、この分岐は存在しないかのように」命令を並べる。しかし、一旦例外がthrowされると、CPUは予測不能な分岐を行い、物理的に離れた`Cold Region`へジャンプする。この「キャッシュミス」こそが、例外の真のコストの正体だ。
2. スタックアンワインディングの「重み」
例外が投げられた瞬間、HHVMのランタイムはC++の`_Unwind_RaiseException`（あるいはプラットフォーム固有のメカニズム）を呼び出す。ここで何が起きているか。
1. レジスタ退避（Spilling）: 実行中の全ての汎用レジスタがスタックに書き出される。
2. スタックウォーク: `.eh_frame`セクションを解析し、フレームポインタを遡りながら、各スタックフレームに登録されたデストラクタ（C++側）や`finally`ブロックを探す。
3. メタデータ検索: どの`catch`ブロックが現在の例外型に適合するかを決定するために、ランタイムは静的に生成されたテーブル（Side Tables）を走査する。
この「テーブル検索」はO(1)ではない。例外が多発するコードは、CPUの分岐予測器を混乱させるだけでなく、メモリバス帯域を消費し、L3キャッシュをフラッシュさせる可能性がある。
3. シニアエンジニアが守るべき「例外設計の極意」
高負荷なサービスにおいて、例外をフロー制御として使うのは「設計の敗北」だ。以下の指針を守れ。
A. 型チェッカーと契約による「例外の静的排除」
Hackの強力な型システム（`Shape`, `Enum`, `Nullable`）を使い、例外が発生する可能性のある境界を明確にせよ。`try-catch`で囲むのではなく、型システムによって「例外が起きないこと」をコンパイル時に証明するのが、最強のパフォーマンスチューニングだ。
B. 境界外の例外は「FATAL」で即死させよ
回収不可能な例外を`catch`して握りつぶすコードは、スタックアンワインディングのコストを支払った挙句、一貫性のない状態を生成する。予期せぬエラーは即座にプロセスを終了させ、HHVMのオーケストレーター（Zend/Hack-worker）に再起動させる方が、システム全体のMTBF（平均故障間隔）は向上する。
C. JITの「Guard」を理解する
Hackコード内の型チェック（`is`演算子や`as`演算子）は、JITにとっては`Guard`として機能する。
- `Guard`が失敗した際の振る舞いは例外と似たコストを払う。
- ループ内での過度な型変換は、JITによるマシンコード生成を何度も「中断（Deoptimization）」させる。
結論：ランタイムを「信じる」な、「支配」せよ
HHVMのJITは魔法ではない。それは、あなたが書いたHackコードの意図を忠実に解釈し、CPUというシリコンの限界まで引き伸ばすための「翻訳機」だ。
例外処理のコストを知るということは、「CPUがどこでメモリアクセスを行い、どこでキャッシュミスが発生し、どこでパイプラインがストールするか」を想像できるということである。
コードを書く際、その`try-catch`が本当に必要なのか、それとも「型」で解決できる問題なのかを自問せよ。例外は、システムが崩壊する瞬間のための最終防衛線であって、日々の処理の流れを制御する手段ではない。
極限のパフォーマンスを求めるならば、コードの「正常系」をいかに美しく、予測可能に保つかに魂を込めろ。それが、Hackを掌握するということだ。