1. イントロダクション：高階関数がHHVM JITにもたらす「最悪のシナリオ」
Hack/HHVMのランタイムは、Facebookスケールのトラフィックをミリ秒未満のレイテンシで処理するために極限まで研ぎ澄まされた、JITコンパイル技術の結晶です。静的型システムであるHackが提供する厳格な型情報は、単なる開発者のバグ防止ツールではありません。それは、HHVMのJITコンパイラがマシンの生の性能を引き出すための「静的証明書」です。
しかし、モダンなプログラミングパラダイスにおいて多用される「クロージャ（匿名関数）」や「高階関数」は、この強固なJIT最適化のチェーンを容易に破壊します。
[高階関数の動的呼び出し]
Func が不確定 ──> 間接分岐（Indirect Call）が発生 ──> 分岐予測ミス（BTBミス）
└──> JITインライン展開の即時停止
関数ポインタ（HHVM内部における `Func`）が動的に変動する場合、JITコンパイラは呼び出し先（Callee）を特定できず、インライン展開（Inlining）を諦めざるを得ません。結果として、実行時には重い関数プロローグ/エピローグの実行、`ActRec`（Activation Record）のスタック構築、そしてCPUの分岐ターゲットバッファ（BTB）を汚染する間接分岐（Indirect Branch）が強制されます。
本稿では、HHVMのJITアーキテクチャの深部に潜り、高階関数がなぜインライン化を阻害するのかを解き明かします。そして、HHVMのJIT（HHIRおよびVASM）にインライン化を「強制」させ、抽象化コストを完全にゼロにするための、極限の関数設計パターンを提示します。
—
2. HHVM JIT（HHIR / VASM）の深部：関数ポインタとクロージャの解剖学
HHVMにおけるクロージャは、単なる関数ポインタではありません。実態は、自動生成された内部クラス（`Closure` を継承するオブジェクト）のインスタンスです。
// HHVM内部におけるクロージャ表現の概念モデル
class Closure$MyFunction extends Closure {
// キャプチャされた環境（変数）
public int $captured_var;
// 実際の関数エントリーポイントへのポインタは、
// オブジェクトヘッダ経由、またはFuncテーブル経由でアクセスされる
public function __invoke(): void {
// 処理本体
}
}
この構造が意味するのは、高階関数にクロージャを渡して実行する際、ランタイムは以下の三重のオーバーヘッドを支払っているということです。
1. オブジェクトの割り当て（Heap Allocation）:
クロージャがローカルスコープをキャプチャする際、多くの場合でヒープ上に `Closure` オブジェクトが確保されます（スマート参照カウンタのインクリメント/デクリメントが発生）。
2. 間接参照の連鎖:
`$closure()` の呼び出しは、オブジェクトから `Func`（関数メタデータ）を取得し、その中にある実際のネイティブコード実行アドレス（TCA: Translation Cache Address）をロードしてジャンプする、という間接参照を伴います。
3. インライン化の障壁:
JITコンパイラが中間表現（HHIR）を生成する際、呼び出し対象の `Func` がコンパイル時に一意に定まらない限り、`CallIndirect` 命令を生成します。これはインライン化のパイプラインを即座に遮断します。
HHIRにおけるコード生成の差異
JITが直接コールと間接コールをどのように処理するか、HHIR（HHVM Intermediate Representation）のレベルでその違いを見てみましょう。
1. 通常の直接呼び出し（インライン化可能、または低コストな直接JMP）
// HHIR Representation
t1:Ptr = LdLocAddr Lmd0
t2:Func = LdFunc “my_static_function” // コンパイル時にアドレスが確定
CCall t2, t1
2. クロージャによる間接呼び出し（インライン化不可能）
// HHIR Representation
t1:Obj = LdLoc Lmd0 // クロージャオブジェクトのロード
t2:Func = LdObjMethod t1, “__invoke” // メソッドテーブルからの動的ロード（間接参照）
CCallIndirect t2, t1 // CPUのレジスタ間接コール（JMP/CALL RAX）
`CCallIndirect` が生成されると、x86-64/AArch64の投機的実行エンジンはターゲットアドレスの予測を強いられます。予測が外れた瞬間、CPUパイプラインは完全にフラッシュされ、数十サイクルのペナルティが発生します。
—
3. JITインライン化を阻害する「壁」：PGOとガード条件
HHVMのJITは、2段階のコンパイルアーキテクチャを採用しています。
1. Profile-Guided Optimization (PGO):
実行初期に、インタープリタや「最適化されていないJITコード（Unique/Profiling Translations）」を実行しながら、プロファイリングデータ（どの関数が、どの型で、どのコールサイトから呼ばれたか）を収集します。
2. Optimized JIT (Optimizing Compiler):
蓄積されたプロファイルデータを基に、最も頻度の高いパスに対して、インライン展開やレジスタ割り当てを極限まで最適化したネイティブコード（Optimized Translations）を再生成します。
高階関数がPGOプロセスに与える最大の影響は、「コールサイトの多相化（Polymorphism）」です。
[Monomorphic Call Site (単一化)]
高階関数 f(g) に、常に同一のクロージャ g1 が渡される
==> JITは g1 をインライン化可能
[Polymorphic / Megamorphic Call Site (多相化)]
高階関数 f(g) に、文脈によって g1, g2, g3… 異なるクロージャが渡される
==> JITはガード条件（Type Check / Func Check）を挿入せねばならず、
分岐が多すぎてインライン化を諦める（汎用コールアウトへのフォールバック）
JITがインライン化を決断するためには、「このコールサイトで呼び出される関数は、100%の確率でこれである」という投機的ガード（Speculative Guard）が成立しなければなりません。高階関数の引数として渡されるクロージャが動的に生成される場合、このガードコード自体が肥大化し、インライン化の恩恵を相殺してしまいます。
—
4. インライン化を「強制」するHackコード設計パターン
では、抽象化の美しさを保ちつつ、HHVM JITにインライン化を強制させるにはどうすればよいか。
以下に、我々がHHVMコア開発と大規模システム構築の現場で導き出した、3つの実践的設計パターンを示します。
パターン1：Reified Genericsと静的インターフェースによるモノモーフィズムの強制
Hackの強力な機能である `reified` ジェネリクスを用い、関数オブジェクトの型情報をランタイムまで引き渡します。これにより、JITは静的な型境界を利用して、呼び出し先を完全に一意に特定できます。
❌ JITが諦めるアンチパターン（動的クロージャの引き回し）
<<__FrameOnStack>>
function process_data(vec
$result = vec[];
foreach ($data as $item) {
// $mapper が何であるか、JITコンパイル時に確定できない（間接呼び出し）
$result[] = $mapper($item);
}
return $result;
}
JITが完全にインライン化可能なパターン（Reified Functor）
// 関数をカプセル化するインターフェース
interface IMapper {
require extends Functor;
public static function apply(int $val): int;
}
abstract class Functor {}
// 具象実装（状態を持たない静的ディスパッチ）
final class IncrementMapper extends Functor implements IMapper {
<<__AlwaysInline>>
public static function apply(int $val): int {
return $val + 1;
}
}
// reified T として具象クラスを型システムとランタイムに強制
<<__AlwaysInline>>
function process_data_optimized
$result = vec[];
foreach ($data as $item) {
// T::apply は静的に解決されるため、JITはこれを直接インライン化できる
$result[] = T::apply($item);
}
return $result;
}
// 呼び出し側
function run(): vec
$data = vec[1, 2, 3];
// 実行時にも IncrementMapper の型情報が引き渡され、JITは完全に最適化されたループを生成する
return process_data_optimized
}
パターン2：`__AlwaysInline` と関数オブジェクトの静的バインディング
HHVMのJITに対して、呼び出し元と呼び出し先の双方に `<<__AlwaysInline>>` アトリビュートを付与し、さらに「クロージャ」ではなく「不変な状態を持つオブジェクト（インライン化可能なメソッドを持つ）」として設計します。
final class Adder {
<<__AlwaysInline>>
public function __construct(private int $operand) {}
<<__AlwaysInline>>
public function add(int $val): int {
return $val + $this.$operand;
}
}
<<__AlwaysInline>>
function perform_math(Adder $adder, int $value): int {
// $adder->add() は、オブジェクトのクラスが Adder に限定されているため、
// JITは間接ルックアップを行わずに直接インライン展開を実行する
return $adder->add($value);
}
パターン3：クロージャの即時実行型ラップ（IIFEパターンによるスコープ局所化）
高階関数をどうしても汎用的に保ちたい場合、呼び出し元で「即座にインライン展開可能なラムダ」として定義し、そのコンテキストが外部にエスケープしないように制限します。
<<__AlwaysInline>>
function execute_flat
// このコールサイトが常にインライン展開されるためには、
// 引数の $callback がこの関数外でアロケーションされないことが条件となる
return $callback();
}
function compute(): int {
$factor = 42;
// JITは、このラムダが外部に流出（Escape）しないことをエスケープ解析（Escape Analysis）で検知する。
// その結果、Closureオブジェクト自体のヒープ確保（Malloc）をスキップし、
// スタック上またはレジスタ上だけで値を処理する（SROA: Scalar Replacement of Aggregates）。
return execute_flat(<<__AlwaysInline>> () ==> $factor 2);
}
—
5. HHVM内部表現（HHIR）のビジュアル表現とメモリレイアウト
上記の最適化を適用した際、HHVMの内部メモリ構造とJITコンパイル後のコードがどのように劇的に変化するかを視覚化します。
非最適化コードのメモリレイアウトと実行フロー
[Stack Frame (ActRec)] ──> [Closure Object (Heap)] ──> [Func (Metadata)] ──> [TCA (Code Address)]
│ │
└── (1) PUSH ActRec ──> (2) Dereference ──> (3) INDIRECT JMP ─────────────────┘
│
[CPU Pipeline Stall!]
最適化済み（インライン展開後）のメモリレイアウトと実行フロー
[Stack Frame (ActRec)]
│ (すべての境界が消滅し、単一の平坦なコードブロックに融合)
▼
[Optimized Native Code (TCA)]
RAX = RAX + 1 // メモリ確保も、間接参照も、関数呼び出しのオーバーヘッドすら存在しない
HHIRレベルで見ると、最適化されたループは、無駄な `LdFunc` や `Call` 命令がすべて消去され、ピュアな算術演算命令とレジスタ間の移動（`Mov`）のみに還元されます。これは、C++で書かれたテンプレートコードがコンパイルされた結果と事実上同等です。
—
6. 結論：ランタイムを支配するための設計思想
高階関数やクロージャは、表現力を高めるための素晴らしい道具です。しかし、HHVMのような高度に最適化されたJITランタイムの上で、ミリ秒以下の極限のパフォーマンスを追求する場合、我々は「JITコンパイラの目」になってコードを書かなければなりません。
1. 動的なディスパッチを静的なディスパッチへと格上げする。
2. Reified Genericsを活用し、型情報をランタイムのJITへの道標（みちしるべ）として機能させる。
3. `__AlwaysInline` とエスケープ解析を意識し、不要なヒープアロケーションを徹底的に排除する。
静的型システムとJITコンパイラが完全に調和したとき、Hackは単なるスクリプト言語の延長ではなく、システムプログラミング言語に匹敵する牙を剥きます。このランタイムの真の力を引き出せるかどうかは、あなたの設計思想にかかっています。