HHVMのインライン展開：JITが関数呼び出しを削減する最適化の限界と恩恵
Hack言語とその実行基盤であるHHVM（HipHop Virtual Machine）の進化を追い続けてきた者にとって、パフォーマンスチューニングの本質は「ランタイムがいかにネイティブに近いコードを生成できるか」の予測と制御に他ならない。
とりわけ、JIT（Just-In-Time）コンパイラによるインライン展開（Inlining）は、関数呼び出しのオーバーヘッドを消し去る強力な最適化である一方、その挙動には明確な物理的・構造的限界が存在する。
本稿では、HHVMのJITパイプラインにおけるインライン展開の内部メカニズムを解剖し、型システムがいかにその最適化を支えているか、そして極限のパフォーマンスを引き出すためにシニアエンジニアがどのようなコード記述スタイルを選択すべきかを詳解する。
—
1. HHVM JITパイプラインとインライン展開のメカニズム
HHVMの実行モデルは、単なるバイトコードのインタープリタではない。Hackの厳格な静的型付け（Strict Mode）の恩恵を受け、Unit（バイトコード）からTC（Translation Cache）へのネイティブ機械語変換のパイプラインは極限まで洗練されている。
呼び出しのコストとインライン化の動機
CPUレベルでの関数呼び出し（`CALL` / `RET` 命令）は、単なるジャンプ命令以上のコストを伴う。
1. レジスタの退避と復元（ABIの規約に則るスタック操作）
2. 分岐予測バッファ（BTB）のミス予測リスク
3. 命令キャッシュ（I-cache）のフットプリント増大
インライン展開は、呼び出し先（Callee）のバイトコード（HHVMの内部表現であるIR）を呼び出し元（Caller）のフローに直接埋め込むことで、これらのオーバーヘッドをゼロにする。
[通常実行]
Caller() —> CALL —> Callee() —> 処理 —> RET —> Callerに戻る
[インライン展開後]
Caller() —> [Calleeの処理が直接展開される] —> 次の処理
しかし、無限にインライン化を行えば、生成される機械語が肥大化し、I-cacheのヒット率が劇的に低下する。「コードの局所性（Locality）」と「関数呼び出し削減」のトレードオフをどこで調停するか——それがHHVMのJITヒューリスティックスの核心である。
—
2. JITがインライン化を諦める「限界点」
HHVMのJIT（RepoAuthoritativeモード下での年間を通した最適化含む）は、静的解析情報をフル活用してインライン化の候補を選定する。しかし、以下の条件に直面した瞬間、JITはインライン化を断念し、通常の関数呼び出し（TCへのジャンパ）へとフォールバックする。
① 巨大な関数サイズ（Bytecode Length Threshold）
HHVMにはインライン化対象となる関数のバイトコード長に厳格な閾値が存在する。ループを多用し、数百バイトを超える関数は、どれほど単純であってもインライン化の恩恵（コード肥大化によるペナルティの回避）を受けられないため、容赦なく除外される。
② 多態性（Polymorphism）と動的ディスパッチ
Hackは厳格な型システムを持つが、トレイト、インターフェイス、またはクロージャ（`Closure`）を介した呼び出しにおいて、型が静的に一意に決まらない（あるいはJITのプロファイリングフェーズで複数の型が観測された）場合、インラインキャッシュ（IC）は失敗する。
モノモーフィック（単一型）であればインライン化の扉が開くが、ポリモーフィックになった瞬間に最適化のパイプラインは塞がれる。
③ 再帰呼び出し（Recursion）
直接的・間接的な再帰関数は、インライン展開のアルゴリズム上、展開深度に上限があるため、基本的にインライン化の対象外となる。
—
3. 型システムがもたらす最適化の恩恵：Hackコードによる検証
Hack言語の厳格な型指定（`<<____AlwaysInline>>` や厳格なプリミティブ型）は、HHVMのJITに対して強力なヒントを与える。
以下のコード例を見てほしい。ここでは、極限のパフォーマンスが要求される演算処理を想定する。
<
namespace HackPerf;
final class VectorMath {
// 故意に小さく設計され、JITによるインライン化の条件を満たしやすいゲッター
private float $x;
private float $y;
public function __construct(float $x, float $y) {
$this->x = $x;
$this->y = $y;
}
// インライン化の候補となりやすい小さく純粋なメソッド
<<__AlwaysInline>>
public function getX(): float {
return $this->x;
}
<<__AlwaysInline>>
public function getY(): float {
return $this->y;
}
}
<<__EntryPoint>>
function main(): void {
$v = new VectorMath(10.5, 20.2);
$acc = 0.0;
// ループ内で頻繁に呼び出されるメソッド群
for ($i = 0; $i < 1000000; $i++) {
// HHVMのJITがこれらを完全にインライン化すれば、
// メソッド呼び出しコストは消滅し、レジスタ上の演算のみに還元される
$acc += $v->getX() $v->getY();
}
echo “Result: ” . (string)$acc . “\n”;
}
JITの内部挙動の解読
上記のコードにおいて、`getX()` および `getY()` に付与された `<<__AlwaysInline>>`（※概念的なアノテーション、またはHHVM内部の最適化ヒント）や、`final` キーワードによるクラスの封印（サブクラスの存在を排除し、ディスパッチを単一化する）は、JITに対して以下の決定的な情報を提供する。
1. クラス階層の静的確定（Devirtualization）: `VectorMath` が `final` であるため、JITは動的なメソッドルックアップ（VTable参照など）を完全に排除し、直接メモリアドレスへのアクセスにコンパイルできる。
2. ボックス化の回避（Unboxing）: 引数や戻り値が厳格な `float`（HHVM内部ではCPUの浮動小数点レジスタに直接載る表現）であるため、PHP時代に見られたZval構造体へのラップ/アンラップのオーバーヘッドが発生しない。
結果として、JITはこのループをネイティブのC++コードと同等のアセンブリ（レジスタ間乗算とインクリメント）へと昇華させる。
—
4. パフォーマンスを最大化するためのコード記述スタイル
HHVMのJITインライン展開の恩恵を限界まで引き出し、予期せぬフォールバックを防ぐためには、以下のアーキテクチャ原則をコードに落とし込む必要がある。
1. 「小さく、単一責任を持った」アクセサの徹底
ロジックを1つの巨大なメソッドに詰め込むのは、JITのインライン化アルゴリズムに対する背信行為である。処理を細分化し、それぞれのメソッドを極小（数行程度）に保つことで、JITが「インライン化すべきブロック」として認識しやすくなる。
2. `final` と strict mode の強制
ポリモーフィズムはオブジェクト指向の美徳だが、極限の演算パフォーマンスを追求するホットパス（Hot Path）においては悪手となり得る。拡張する必要のないドメインモデルや値オブジェクト（Value Object）には必ず `final` を付与し、型推論の不確実性を排除せよ。
3. クロージャや高階関数の乱用に警戒する
`array_map` や `array_filter` に渡される無名関数（Closure）は、JITのインライン化を複雑にする。特に外部スコープの変数をキャプチャするクロージャは、環境構造体の生成を伴うため、JITが最適化を諦めるトリガーになりやすい。極限の速度が求められるホットパスでは、あえて素朴な `for` ループを選択することがエンジニアリング上の正しい判断となる。
—
5. 総括
HHVMのJITコンパイラは魔法の箱ではない。それは、私たちが書いたHackコードの静的な構造と型情報を元に、確率的に最も効率の良いネイティブコードを推論・生成する極めて合理的なエンジンである。
インライン展開の限界を理解し、ランタイムが最適化しやすい「境界の明確なコード」をデザインすること。それこそが、シニアエンジニアが持たなければならない、低レイヤに裏打ちされた真のコード品質なのである。