虚飾を剥ぎ取れ：HHVM JITが「関数呼び出し」を消滅させる瞬間の真実
Hackの静的型システムは、単なる「型安全のための制約」ではない。それは、HHVMのJITコンパイラに対して、実行時に発生する曖昧さを排除し、機械語レベルでの最適化を強要するための「指令書」だ。
多くの開発者は、関数を小さく分割し、DRY原則に従うことを良しとする。しかし、HHVMの深淵において、安易な関数呼び出しは性能を殺す毒となる。今日は、JITコンパイラが何を基準にコードをインライン展開し、我々がそれをどう制御すべきか、その設計思想の根幹を解剖する。
—
1. インライン化という名の「トレードオフ」
HHVMのJIT（特にバックエンドの`HHBC`から`IR`への変換フェーズ）におけるインライン化は、単なるコードの埋め込みではない。それは「呼び出し元(Caller)」と「呼び出し先(Callee)」のコンテキストを統合し、レジスタ割り当てのスコープを拡大するプロセスだ。
JITがインライン化を決定する際、内部で評価されるヒューリスティックの核心は以下の3点にある：
1. Calleeの複雑度（IR命令数）: インライン化後のコードサイズが、命令キャッシュ（I-Cache）の局所性を破壊しないか。
2. 呼び出し頻度（プロファイルデータ）: PGO（Profile-Guided Optimization）によって蓄積されたホットパス上の呼び出しであるか。
3. 型推論の確実性: コンパイル時にCalleeの型が完全に確定しているか。
なぜ「型」がインライン化を左右するのか
もしCalleeの型が `mixed` や `dynamic` に近い状態であれば、JITはインライン化の直前に「型ガード（Type Guard）」を挿入せざるを得ない。このガードが生成されると、インライン化によるオーバーヘッド削減分を、ガードの分岐予測ミスが食いつぶす。つまり、型を絞り込めない関数は、インライン化の恩恵を受けられない。
—
2. JITを「その気にさせる」コード設計
インライン化を強制、あるいは誘導するために、我々が守るべき設計の鉄則がある。
A. 型の曖昧さを物理的に排除する
`HH\vec` や `HH\dict` を使用する際、ジェネリクスを省略してはならない。
// 良い例: 型が確定しており、JITが推論の迷路に迷い込まない
function process
// ここでの加算はレジスタ上で完結する
return array_sum($data);
}
型が `T` として固定されていれば、JITはCallee内部の加算命令をSSE/AVX命令へ直結できる。逆に型が不明瞭だと、HHVMは内部のランタイム関数を呼び出し、タイプチェックを繰り返す羽目になる。
B. 「ホット」な関数を極小に保つ
HHVMのインライン化制限は、関数の「重さ」によって動的に変わる。巨大な関数は、どれほど呼び出し頻度が高くてもインライン化の候補から外される。
- 戦略: ループ内で頻繁に呼ばれるロジックは、極限まで小さくし、`__AlwaysInline`に近い挙動を期待できる状態にする。
—
3. メモリ管理とレジスタ・プレッシャー
インライン化の真の目的は、関数呼び出しのスタック操作（フレーム構築）をスキップすることだけではない。真の狙いは「レジスタ割り当ての最適化」にある。
関数をまたぐと、呼び出し側はレジスタをスタックに退避（Spill）させなければならない。これはCPUにとって最も高コストなメモリI/Oの一つだ。インライン展開されたコードブロックでは、コンパイラはグローバルなデータフロー解析を行い、可能な限りCPUレジスタ内に変数を留まらせる。
シニアエンジニアへの忠告：
関数呼び出しを減らしたいがために、巨大なモノリシックな関数を作るな。それは、コンパイラのレジスタ割り当てアルゴリズムを破綻させ、逆にスタックへの退避回数を増やす（Spillの爆発）。適度な粒度を保ちつつ、型を明示することでコンパイラに「この関数はインライン化してもリスクがない」と確信させるのが、最高峰のチューニングだ。
—
4. 結論：コードは「機械」のために書け
HHVMという巨獣を制御するには、人間が読みやすいコードから、機械が最適化しやすいコードへと視座を移す必要がある。
- 型は最強のヒント: 全ての引数、戻り値に厳格な型を定義せよ。
- プロファイル駆動の意識: 実行頻度の高いパスでは、多態性（Polymorphism）を避けよ。
- 計測なき最適化は罪: `hhvm.jit_a_size` などの統計情報を追い、実際にインライン化が成功しているか、あるいは命令キャッシュが溢れていないかを見極めよ。
Hackのパワーを最大限に引き出すのは、言語仕様の表面をなぞる者ではない。JITの深淵、CPUのキャッシュライン、そして型システムの静かなる警告を理解した者だけが、その性能の天井を突き破ることができる。
コードを書くとき、自問せよ。「この関数呼び出しは、CPUにとってのノイズになっていないか？」と。その問いの先に、真の高速化がある。