迷宮のJITを読み解く：try-catchが「コスト」に変わる瞬間
Hackエンジニア諸君。君たちはコードを書くとき、`try-catch`を単なる「エラーハンドリングの道具」としか見ていないのではないか？
もしそうなら、君たちの書くコードはHHVMのJIT（Just-In-Time）コンパイラにとって、「最適化の翼をもがれた重石」でしかない。今日は、この華麗な仮想マシンの深層で、例外処理がどのようなマシン語を生成し、なぜ君たちのアプリケーションのCPUサイクルを無駄に食いつぶしているのかを解剖しよう。
—
1. 舞台裏：JITは「try-catch」をどう見るか
HHVMのJITコンパイラは、コードを単なる命令列ではなく、制御フローグラフ（CFG）として解釈する。ここで重要なのは、`try-catch`ブロックが「制御フローの分断」を引き起こすという点だ。
JITの最適化を阻む「見えない壁」
JITが関数のインライン化やレジスタ割り当てを行う際、`try-catch`が存在すると、コンパイラは「このブロック内で例外が発生した場合、スタックの状態を確実に巻き戻さなければならない」という制約を背負う。
- レジスタ退避の強制: `try`ブロック内では、例外発生時に備えて、レジスタに保持している値を頻繁にメモリへフラッシュ（ストア）しなければならない。これはCPUパイプラインにとって致命的な遅延要因となる。
- インライン化の抑止: HHVMのJITは、最適化の境界線に「例外ハンドラ」が横たわっていると、その関数のインライン化を躊躇する。結果、関数呼び出しのオーバーヘッドがそのまま残る。
—
2. 例外発生時：スタックトレースという名の重い代償
例外が実際にスローされた瞬間、HHVMはスタックトレースを構築するためにVMのスタックを逆方向にたどる。この処理は「重い」。
1. フレームの走査: VMのスタックフレームを一つずつ遡り、シンボル情報を照合する。
2. メモリ割り当て: トレース情報を保持するために、ヒープ上にメモリを確保する。
3. キャッシュミス: 物理メモリ上の広い範囲にアクセスするため、CPUキャッシュラインが汚染される。
これをループ内で頻発させる設計は、パフォーマンスに対する冒涜だ。
—
3. 実践：例外に頼らない「美しい」設計パターン
例外を「制御フローの一部」として使うのは設計の敗北だ。ビジネスロジックで発生しうる予測可能な事象は、型システムで表現し、`Result`型（あるいは`Either`パターン）で扱うべきだ。
以下のコードを見てほしい。これが、パフォーマンスと保守性を両立させるプロダクションレベルの「Hack的回答」だ。
<<__ConsistentConstruct>>
abstract final class Result<+T, +E> {
// 例外を投げず、型で結果を表現する
public function isSuccess(): bool { return $this is Success
}
final class Success
public function __construct(public T $value) {}
}
final class Failure
public function __construct(public E $error) {}
}
// — 利用例 —
function fetchUserBalance(int $userId): Result
if ($userId <= 0) {
// 例外を投げない。型安全にエラーを返却
return new Failure("Invalid User ID");
}
// 正常系
return new Success(1000);
}
// 呼び出し側もtry-catchに頼らない
function processPayment(int $uid): void {
$result = fetchUserBalance($uid);
// マッチングで処理を分岐。JITもこのフローを予測しやすく最適化が効く
if ($result is Success<_>) {
// 成功時のロジック
echo “Balance: ” . $result->value;
} else {
// 失敗時のロジック（型が絞り込まれているため安全）
echo “Error: ” . $result->error;
}
}
なぜこの設計が優れているのか？
1. JITフレンドリー: 制御フローが直列化され、分岐予測が容易になる。`try-catch`のような「異常系への大ジャンプ」が発生しない。
2. 型安全性: `Result`型を使うことで、呼び出し側は必ずエラーの処理を強制される。`catch`ブロックを書き忘れてランタイムエラーになる悲劇は二度と起きない。
3. 可読性: 関数が何を返すか（正常値かエラーか）がシグネチャを見ただけで明確になる。
—
4. チーフアーキテクトからの助言
君たちがシステムを構築する際、以下の原則を胸に刻んでほしい。
- 例外は「例外的な状況」にのみ使え: データベース接続の断絶や、メモリ不足のような「復旧不可能なシステムエラー」のみに例外を許可せよ。
- ビジネスロジックに例外を混ぜるな: バリデーションエラーや「対象が見つからない」といった事象は、ドメイン層の型システムで吸収せよ。
- プロファイラを信じろ: コードの複雑さに迷ったら、HHVMのプロファイラ（`hhvm.jit.stats`など）を回し、どの程度「例外処理」がJITの実行コードに影響を与えているか可視化せよ。
Hackは、君たちが思っている以上に強靭な言語だ。だが、その力を引き出すのは、言語を信じ、その底流にあるVMの挙動を理解しようと努める君たちの知性だけだ。
次回のコードレビューで、不要な`try-catch`が紛れ込んでいないことを期待している。健闘を祈る。