HHVM JITの深淵：脱出解析（Escape Analysis）を掌握し、オブジェクトのヒープ割り当てをゼロにする極限のHackコード設計
HHVM（HipHop Virtual Machine）のJITコンパイラは、PHP/Hackのコードを極限まで高速化するために、バックグラウンドで凄まじい最適化を行っています。その中で、メモリ帯域とGC（ガベージコレクション）/参照カウントのオーバーヘッドを劇的に削減する最重要機構の一つが「脱出解析（Escape Analysis: EA）」です。
しかし、多くのWebエンジニアは「型が通っているから」「動いているから」という理由で、HHVMのJIT最適化ロードマップを自ら破壊するコードを量産しています。
本記事では、HHVMのチーフアーキテクトの視点から、HHVMのJIT（特にHHIR: HipHop Intermediate Representation）がどのように脱出解析を行い、オブジェクトをスタック（あるいはレジスタ）に昇格させるかを解き明かします。そして、JITを味方につけ、限界までアロケーションフリーなコードを書くための具体的な設計パターンを伝授します。
—
1. なぜ「ヒープ割り当て」は悪なのか？ HHVMメモリモデルの現実
HHVMは、スレッドローカルな高速アロケータ（`smart_alloc`）を採用しているため、標準的な`malloc`に比べればメモリ確保は非常に高速です。しかし、それでもオブジェクトをヒープに割り当てることには以下の重いコストが伴います。
1. 参照カウントの増減（RefCount Churn）: Hack/PHPのオブジェクトは参照カウントで管理されます。関数をまたぐたびに、あるいは一時変数に代入するたびに、アトミック（またはスレッドローカル）なカウントの増減（`incRef` / `decRef`）が発生し、これがCPUキャッシュを汚染します。
2. メモリの断片化とデストラクタの登録: オブジェクトのライフサイクル終了時に、デストラクタの追跡やスイープ処理が必要になります。
3. 間接参照の発生: ヒープ上のオブジェクトのプロパティにアクセスするたびに、ポインタをデリファレンス（間接参照）する必要があり、CPUのロードポートを消費します。
もし、オブジェクトが「その関数（およびインライン化された呼び出し先）の内部だけで使われ、外部に漏れ出さない（Escapedしない）」ことが保証できれば、JITはオブジェクト自体の生成を完全にキャンセルできます。
これをスカラー置換（Scalar Replacement of Aggregates）と呼びます。オブジェクトの各プロパティを個別のローカル変数（レジスタまたはスタック）へと分解し、あたかもオブジェクトなど最初から存在しなかったかのようにマシンコードを生成するのです。
—
2. HHVM JITにおける「脱出解析」のメカニズム
HHVMのJITは、Hackコードを一度「HHBC（Bytecode）」に変換し、それをさらに「HHIR（HHVM Intermediate Representation）」と呼ばれる強力な中間表現にコンパイルします。
HHIRの最適化フェーズにおいて、脱出解析器はオブジェクトを生成する命令（`NewObj` や `AllocObj`）から出発し、そのオブジェクトのポインタ（`SSATmp`）がたどる経路をデータフロー解析します。
[AllocObj] —> [SetProp] (プロパティ設定)
|
+———> [Call] (外部メソッドに引数として渡す) —> ここで「脱出」の危険性！
解析器が「このオブジェクトは絶対に呼び出し元メソッドの外に出ない」と判定（`NoEscape`）した場合、以下の最適化がトリガーされます。
1. オブジェクト割り当ての排除: `AllocObj` 命令を完全に消去。
2. プロパティのレジスタ化: プロパティへの `SetProp` / `GetProp` は、単なるレジスタ間の移動（`Mov`）やスタックローカル変数へのアクセスに置き換わります。
3. デストラクタの排除: 参照カウントの操作コードが1命令も生成されません。
脱出（Escape）と判定される主なトリガー
以下のいずれか1つでも満たすと、HHVMは最適化を諦め、オブジェクトをヒープに割り当てます。
- グローバルまたは