HHVMの深淵：JITコンパイルにおける例外処理のコストと、Hack言語による極限の最適化
コードレビューをしていて、次のようなコードに出くすことはないだろうか。
// 典型的な「思考停止型」の例外ハンドリング
public function processPayload(string $json): ?array {
try {
$data = json_decode($json, true, 512, JSON_FB_THROWS);
$this->validate($data);
return $data;
} catch (\Exception $e) {
// ログを残してnullを返す
Logger::error($e->getMessage());
return null;
}
}
一見して、何の問題もない安全なコードに見えるかもしれない。しかし、HHVM（HipHop Virtual Machine）のアーキテクチャ、そしてJIT（Just-In-Time）コンパイルの挙動を熟知するエンジニアの目から見れば、このコードはパフォーマンスの地雷原であり、静的型システムの恩恵を自らドブに捨てる愚行に他ならない。
今回は、HHVMのJITパイプラインにおいて`try-catch`ブロックがネイティブコード生成にどのような爪痕を残すのか、そして例外発生時のコストをゼロ近傍まで押し下げるための実務的な設計パターンを、コアコミッターの視点から徹底的に解説しよう。
—
1. 为什么 `try-catch` 是 JIT の最適化を阻害するのか
HHVMのJITエンジン（現在は主にLLVMベースの翻訳パイプラインやTC（Translation Cache）を使用）は、PHP/Hackの動的なセマンティクスを静的かつアグレッシブなマシン語へと変換する。
ここで重要になるのが Control Flow Graph (CFG) と Deoptimization（最適化の破棄） の関係だ。
① 投機的最適化（Speculative Optimization）の崩壊
JITは、「この変数は常に`shape`構造を維持している」「この関数呼び出しは例外を投げない」というプロファイル情報（PGO: Profile-Guided Optimization）に基づき、インライン展開やレジスタ割り当ての最適化を行う。
しかし、コード内に`try-catch`が存在する瞬間、JITコンパイラは「ここで何が起きても安全に例外オブジェクトを構築し、スタックトレースをキャプチャできる状態」を強制される。これにより、以下のコストが発生する。
- レジスタ退避の強制: 例外発生時に備え、変数の状態をメモリ上の正確なスタックフレームに同期（Spill）させ続けなければならない。レジスタ上で高速に完結できたはずの演算が阻害される。
- CFGの肥大化: 例外エッジ（Exception Edge）がすべての演算命令に追加されるため、基本ブロック（Basic Block）の数が爆発的に増え、JITの最適化パス（Dead Code EliminationやGVNなど）の計算量が跳ね上がる。
② 例外発生時の「重すぎる」コスト
例外が実際にスローされたとき、HHVMは以下の処理を実行する。
1. 現在の実行コンテキストのアンワインド（Unwinding）。
2. スタックトレースの生成（これが最も重い。ファイル名、行番号、シンボル情報の解決）。
3. catchブロックの探索と制御フローのジャンプ。
これは数千クロックサイクルを消費する。高スループットが求められるWeb APIや非同期I/Oのコンテキストにおいて、「制御フローの制御に例外を使う」ことは、自らスループットを制限しているのと同じだ。
—
2. Hack言語の厳格な型システムによる「例外の排除」
幸いにして、我々にはHack言語がある。Hackには、動的な例外に頼らずとも、エラーや異常系を美しく、かつゼロコストで伝播させるための強力な武器が揃っている。
それが `Result` 型パターン （またはそれに準ずる網羅的な直和型（Union Types）の活用）だ。
悪い設計：例外駆動型
// 失敗するたびに例外を投げる（JITにとっても最悪）
function divide(int $a, int $b): int {
if ($b === 0) {
throw new DivisionByZeroException(“Division by zero”);
}
return intdiv($a, $b);
}
良い設計：Result型による値ベースのエラーハンドリング
HackのジェネリクスとShape/Enumを組み合わせることで、例外を一切使わずに安全性を担保できる。
<<__EnforceGenerics>>
enum ErrorCode: int {
INVALID_JSON = 1;
VALIDATION_FAILED = 2;
DIVISION_BY_ZERO = 3;
}
type Result
‘success’ => bool,
‘value’ => ?T,
‘error’ => ?E,
);
class ResultHelper {
public static function ok
return shape(‘success’ => true, ‘value’ => $value, ‘error’ => null);
}
public static function err
return shape(‘success’ => false, ‘value’ => null, ‘error’ => $error);
}
}
このアプローチであれば、JITは条件分岐（`if`）を純粋な条件ジャンプとしてネイティブコードにコンパイルでき、例外オブジェクトの生成やスタックトレースのキャプチャといった重い処理を完全にバイパスできる。
—
3. プロダクションコード：型安全かつ高速なペイロード処理パイプライン
実際のWebアプリケーション開発において、外部API連携やJSONパースは避けて通れない。ここで、HHVMのJIT特性を最大限に活かしつつ、保守性と堅牢性を極限まで高めたプロダクションコードの設計パターンを提示する。
namespace App\Core;
/
- 厳格な型付けとJIT最適化を意識したペイロードプロセッサ
/
<
type ProcessError = shape(
‘code’ => int,
‘message’ => string,
);
type PayloadData = shape(
‘user_id’ => int,
‘action’ => string,
‘meta’ => darray
);
class PayloadProcessor {
/
- 例外を投げずに、Result型で結果を返す。
- JITはこのメソッドをインライン展開しやすく、非常に高速な機械語を生成する。
/
public static function process(string $rawJson): shape(‘success’ => bool, ‘data’ => ?PayloadData, ‘error’ => ?ProcessError) {
// 1. JSONパース時の例外をラップする
// json_decodeの例外オプションは使わず、戻り値の型チェックで担保する
$decoded = json_decode($rawJson, true);
if (!\is_array($decoded)) {
return shape(
‘success’ => false,
‘data’ => null,
‘error’ => shape(‘code’ => 1001, ‘message’ => ‘Invalid JSON format’)
);
}
// 2. 構造のバリデーション（HackのTypecheckerとJITの相性が最も良い形）
$typedData = self::hydrateAndValidate($decoded);
if ($typedData[‘error’] !== null) {
return shape(
‘success’ => false,
‘data’ => null,
‘error’ => $typedData[‘error’]
);
}
return shape(
‘success’ => true,
‘data’ => $typedData[‘data’],
‘error’ => null
);
}
private static darray
// 必須キーの存在チェックと型の強制
$userId = $raw[‘user_id’] ?? null;
$action = $raw[‘action’] ?? null;
$meta = $raw[‘meta’] ?? null;
if (!\is_int($userId) || $userId <= 0) {
return shape(
'data' => null,
‘error’ => shape(‘code’ => 2001, ‘message’ => ‘Field “user_id” must be a positive integer’)
);
}
if (!\is_string($action) || \strlen($action) === 0) {
return shape(
‘data’ => null,
‘error’ => shape(‘code’ => 2002, ‘message’ => ‘Field “action” must be a non-empty string’)
);
}
if (!\is_array($meta)) {
return shape(
‘data’ => null,
‘error’ => shape(‘code’ => 2003, ‘message’ => ‘Field “meta” must be an array’)
);
}
$validated: PayloadData = shape(
‘user_id’ => $userId,
‘action’ => $action,
‘meta’ => $meta,
);
return shape(‘data’ => $validated, ‘error’ => null);
}
}
この設計が優れている理由（コードレビューの視点から）
1. 例外の撲滅: 業務ロジックの主経路（Happy Path）において、`try-catch`が一切存在しない。これにより、HHVMのJITは予測可能な直線的なマシン語を生成し、レジスタ割り当てが最適化される。
2. 型チェッカーの完全な掌握: Hackの静的型チェッカー（`hh_client`）がすべての配列キーと型をコンパイル時に検証するため、実行時エラー（Undefined indexなど）の心配がない。
3. 予測可能なエラーハンドリング: 呼び出し側は、戻り値の`success`フラグを見るだけで分岐処理を書けるため、コードの可読性が飛躍的に向上する。
—
4. チーフアーキテクトからの提言：例外を使うべき唯一の例外
ここまで「例外を排除せよ」と説いてきたが、勘違いしてはならない。すべての例外が悪というわけではない。
「プログラムの継続が不可能な致命的な異常（Out of Memory, Disk Full, 外部インフラの完全な崩壊）」に関しては、例外（あるいはパニック）を投げるべきだ。これらはリカバリ不能な異常系であり、迅速にプロセスを落とす、あるいはリクエストをアボートさせるべきだからである。
しかし、バリデーションエラー、外部APIからの期待されたエラーレスポンス、データの不整合といった「業務上起こりうる想定内の異常」を例外で表現してはならない。それはJITのパフォーマンスを殺すだけでなく、システムのロバスト性を低下させるアンチパターンだ。
次回のコードレビューでは、`try-catch`の波括弧を見つけたらこう問いかけてほしい。
「その例外、本当にJITを焼き払ってまで投げる必要がありますか？」
Hack言語の静的型システムとHHVMのアーキテクチャのポテンシャルを極限まで引き出し、真にスケーラブルなシステムを構築してほしい。