HHVM JITの深淵：コードキャッシュの飽和を制御し、メモリの限界を突破する
HHVMのJITエンジンは、単なる「バイトコードのネイティブ変換機」ではない。それは、実行時に絶えずプロファイリングを行い、型推論の境界を動的に最適化する、生きた最適化コンパイラだ。
しかし、大規模なHackアプリケーションにおいて、この強力なエンジンは諸刃の剣となる。特に`Repo Authoritative`モードでさえ制御しきれない「コードキャッシュ（TC: Translation Cache）」の膨張は、メモリ管理における最大級のボトルネックだ。
今日は、HHVMのJITがどのようにメモリを喰らい尽くし、我々がそれをどう支配下に置くべきか、その極限の知見を共有する。
—
1. 翻訳キャッシュ（TC）の物理的制約を知る
HHVMのJITは、生成されたマシンコードを「TC（Translation Cache）」という固定サイズのメモリ領域に配置する。`Eval.JitPGO`（プロファイルガイド最適化）が有効な場合、プロファイリングデータと生成されたコードが混在し、キャッシュ領域を急速に枯渇させる。
このキャッシュが溢れると、HHVMは「TC eviction（追い出し）」を開始する。これは、古いマシンコードを破棄し、再生成するためのコストを支払うことを意味する。最悪の場合、ループ状のコード再生成が発生し、CPU使用率がスパイクする「スラッシング」に陥る。
制御すべき主要パラメータ
まずは、以下の設定値があなたの環境で適切か再確認せよ。
; 翻訳キャッシュの最大サイズ（デフォルトは環境依存だが、大規模アプリなら拡張必須）
Eval.JitTransCacheSize = 1073741824 ; 1GBを確保する例
; 追放ポリシーの微調整
Eval.JitEvictAllOnTransCacheFull = true ; 満杯時に全フラッシュ（再帰的な再生成を防ぐための防衛的措置）
—
2. PGO（プロファイルガイド最適化）の二面性
PGOは、実行時の型情報をフィードバックして、より厳密なネイティブコードを生成する。しかし、過剰な多態性（Polymorphism）を持つコードに対してPGOを適用すると、JITは「特定の型」に特化した無数のガード付きマシンコードを生成し、キャッシュを爆発させる。
対策：ジェネリクスの活用と型制約の強化
Hackの型システムは単なる飾りではない。`HH\Vector
// 良い例: 型が明示的であれば、JITは単一のパスを生成できる
function process_data(vec
$sum = 0;
foreach ($items as $i) {
$sum += $i;
}
return $sum;
}
// 悪い例: 混合型はJITに大量の「型ガード」を生成させ、キャッシュを食いつぶす
function process_unsafe(vec
$sum = 0;
foreach ($items as $i) {
// ここでJITは $i が int か、float か、あるいはオブジェクトかを判断するガードを生成する
if ($i is int) $sum += $i;
}
return $sum;
}
—
3. インライン化の制限と制御
JITの「インライン化（Inlining）」はパフォーマンスを劇的に向上させるが、同時にマシンコードのサイズを指数関数的に増加させる。特に再帰的な関数や、巨大なヘルパー関数をインライン化させると、キャッシュは一瞬で消し飛ぶ。
以下のフラグで、インライン化の攻撃性を調整せよ。
; インライン化の深さを制御（デフォルト値は過剰な場合がある）
Eval.JitInlineMaxDepth = 2
; インライン化する関数のサイズ制限
Eval.JitInlineMaxUnits = 5
—
4. 観測：どのコードがキャッシュを殺しているか
推測は禁物だ。HHVMには、どの関数がどれだけのTCを占有しているかを可視化するメトリクスが存在する。`hhvm.jit.stats`を追跡し、以下のコマンドで現状をスナップショットせよ。
現在のJITメモリ使用状況を確認する内部コマンド
hhvm –admin-server-port=9090 &
curl http://localhost:9090/stats
ここで`jit.trans_cache.used`と`jit.trans_cache.free`の比率を監視し、80%を超えて推移しているなら、それはアーキテクチャ上の転換点だ。
—
5. チーフアーキテクトからの提言
大規模システムにおいて、JITキャッシュのメモリ消費を最適化する究極の手段は、「コードの静的な予測可能性」を最大化することだ。
1. Strict Typingの徹底: `<<__Strict>>`を全ファイルに適用し、HHVMが型ガードを生成する必要がないほどコードを明瞭にせよ。
2. Hot Pathの分離: 滅多に実行されないエラーハンドリングやログ出力用コードは、独立した小さな関数に追い出し、JITのインライン対象から外せ。
3. Hot Profilingの調整: `Eval.JitPGO` を本番環境で回すのは強力だが、メモリコストも高い。ローカルまたはQA環境で収集したプロファイルデータを `repo authoritative` モードのバイナリに焼き付ける手法に移行せよ。
JITキャッシュは、我々が「実行の効率」を買うために支払う税金だ。しかし、無駄な贅肉（多態性の放置や過剰なインライン化）を削ぎ落とせば、その税率は最小化できる。
システムを掌握せよ。VMが何を考え、どこでメモリを確保し、どう命令を変換しているか。その一挙手一投足に意識を向ける者だけが、高負荷時においても揺るぎない安定したアーキテクチャを構築できる。
以上だ。コードの深淵へ戻るとしよう。