HHVMのJIT生成コードにおけるレジスタ割り当て戦略：なぜHackの型情報がレジスタ効率を劇的に向上させるのか
コードレビューをしていて、動的言語上がりのエンジニアから「Hackは静的型付けの恩恵でコード補完が効いて便利だよね」という浅い感想を聞くたび、私は密かに苦笑いする。
甘い。TypeScriptやJavaの静的型付けと同列に語ってもらっては困る。
Hack言語における厳格な静的型システム（Strict Mode）とHHVM（HipHop Virtual Machine）のJITコンパイラは、水面下でCPUの物理レジスタを極限まで効率的に使い倒すための高度な共犯関係を結んでいる。
今回は、HHVMのJIT生成コードにおけるレジスタアロケーション（レジスタ割り当て）の内部構造を紐解き、なぜHackの型情報が「スピル（Spill）」を劇的に削減し、圧倒的なスループットを生み出すのか、その深淵なるメカニズムをコードレビューの視点から解説しよう。
—
1. 動的PHPの悲劇：なぜJITはレジスタ不足に陥るのか
従来のPHP（PHP 7/8のOpcache + JIT環境であっても）や、純粋な動的言語では、変数の型が実行時まで確定しない。
これがJITコンパイラにとって最大の悪夢となる。
CPUの物理レジスタ（x86-64であれば一般目的レジスタは高々16個程度）は有限の資源だ。JITコンパイラは、頻繁にアクセスされる変数をレジスタ上に常駐させたい。しかし、動的言語では以下のような問題が発生する。
- 型の不確実性: ある変数が整数（`int`）として使われていた直後に、文字列（`string`）やオブジェクトに変化する可能性がある。
- ボクシング（Boxing）の強制: 型が不定であるため、値そのものではなく「型タグ付きの共用体（Tagged Union）」としてメモリ上に確保し、レジスタ間を移動させる際も余分なメタデータのハンドリングが必要になる。
- レジスタの退避（スピル）: レジスタが足りなくなると、CPUは一時的にレジスタの値をスタック領域（メモリ）に書き出さざるを得なくなる（スピル）。このメモリへのアクセス（Cache Missの温床）こそが、Webアプリケーションのレイテンシを悪化させる最大のボトルネックだ。
—
2. Hackの型情報がHHVMのJITをもたらすパラダイムシフト
Hack言語がファイル先頭で `<<__STRICT__>>` を強制し、すべてのパラメータ、プロパティ、戻り値に厳格な型を要求する理由。それは単なる「静的解析によるバグの早期発見」にとどまらない。
「型が完全に確定している」という事実が、HHVMのJITコンパイラ（特にTC: Translation Cache生成フェーズ）に強力な最適化の自由度を与えるのだ。
レジスタアロケータの最適化フロー
1. アンボクシング（Unboxing）の徹底:
Hackの `int` や `float` は、CPUが直接理解できるネイティブな64ビット整数や倍精度浮動小数点数として、そのまま物理レジスタに直結される。余分な型タグの評価は一切不要だ。
2. ライフレンジ（Live Range）の精密解析:
静的型によって変数のサイズと寿命（スコープ）が完全にコンパイル時に確定するため、グラフ彩色法（Graph Coloring）に基づくレジスタアロケータが、レジスタの衝突を最小限に抑えて配置できる。
3. スピル劇的削減:
CPUのキャッシュラインを汚染するスタックへの退避・復帰命令（`push`/`pop` やメモリウムロード/ストア）が極限まで削ぎ落とされる。
結果として、HHVMが生成する機械語は、C++やRustが吐き出すそれに肉薄する極めてタイトなループ構造を持つことになる。
—
3. 【コードレビュー】非効率な設計 vs 堅牢で美しいプロダクションコード
現場のコードレビューでよく見かける「型が曖昧なコード」と、HHVMのJIT効率を最大限に引き出す「完全なStrictモードコード」の対比を見てみよう。
❌ 悪い例：型が曖昧でJIT効率を殺すコード
// <<__STRICT__>> が抜けている、あるいは mixed を多用したレガシーな記述
class UserProcessor {
// 戻り値も引数も mixed。これではJITは型推論を諦め、ボクシング処理を生成する
public function calculateMetrics(array $data): mixed {
$total = 0;
foreach ($data as $item) {
// 実行時まで $item[‘score’] の型が分からないため、
// 毎回動的な型チェックとメモリ参照が発生し、レジスタが圧迫される
$total += $item[‘score’] ?? 0;
}
return $total;
}
}
テックリードの指摘:
> 「この実装では、HHVMはループ内で毎回コストの高い型ガードを挿入せざるを得ません。結果としてレジスタがスピルしまくり、CPUキャッシュ効率が最悪になっています。全面的に書き換えてください。」
—
⭕ 良い例：HHVMのJIT性能を極限まで引き出すプロダクションコード
以下のコードは、厳格な型定義によりJITコンパイラに「この変数は絶対に64bit整数である」と確信させ、物理レジスタへの完全な常駐化を促す設計パターンだ。
<<__STRICT__>>
namespace App\Performance;
/
- ユーザーのメトリクスを高速に集計するドメインサービス。
- 完全な静的型付けにより、HHVMのJITアロケータにネイティブRegisterをフル活用させる。
/
final class MetricsAggregator {
/
- スコアの合計値を算出する。
- @param vec
$scores ネイティブな整数ベクター（連続メモリ領域） - @return int
/
public function aggregateScores(vec
// $total はローカル変数として、CPUの汎用レジスタ（例: %rax）に完全に固定化される
// メモリ上のスピルは発生しない
var $total = 0;
// vec に対する最適化されたイテレーション
foreach ($scores as $score) {
// CPUの加算命令（ADD）に直接マッピングされる
$total += $score;
}
return $total;
}
}
// — 実行検証用スニペット —
<<__EntryPoint>>
function main(): void {
$aggregator = new MetricsAggregator();
// vec
// HHVMはこの構造体を把握しているため、要素アクセスにオーバーヘッドがない
$scores = vec[100, 250, 300, 450, 900];
$result = $aggregator->aggregateScores($scores);
\C\print_f(“Total Score: %d\n”, $result);
}
このコードが美しい理由（アーキテクチャの観点から）
1. `vec
2. プリミティブ変数のレジスタ常駐: `$total` や `$score` はすべてネイティブな整数として扱われ、JITのレジスタアロケータによって物理レジスタ上にアロケートされるため、インメモリの読み書き（スピル）がゼロになる。
3. `final` キーワードと厳格性: クラスを `final` にすることで、HHVMはディスパッチ時のメソッドインライン化（Devirtualization）を積極的に行い、関数呼び出しのオーバーヘッドすら消し去る。
—
4. まとめ：コードの書き方が、そのままハードウェアの効率に直結する
Webアプリケーションの開発において、「可読性」や「保守性」が重要であることは言うまでもない。しかし、Hack言語とHHVMの組み合わせにおいては、「厳格な型を書くこと」そのものが、そのままハードウェア資源（CPUレジスタとキャッシュ）の最適利用に直結する。
動的な甘えを捨て、型という規律をコードに刻むこと。それこそが、数百万リクエストを捌く高負荷システムを支えるテクニカルリードの嗜みであり、Hackという言語の真骨頂を骨の髄までしゃぶり尽くすアプローチなのだ。
次のコードレビューでは、曖昧な型を見つけたらこう問いかけてほしい。
「そのコード、HHVMのレジスタアロケータを泣かせてないか？」 と。