HHVMの深淵：JITキャッシュの「メモリ食い」を制し、プロダクションの安定を極める
Hackを扱う我々にとって、HHVMのJIT（Just-In-Time）コンパイラは魔法の杖だ。しかし、大規模なコードベースを運用していると、その魔法は時に牙を剥く。JITが生成するマシンコード（TC: Translation Cache）がメモリを喰らい尽くし、OOM（Out of Memory）を誘発する――これは、アーキテクチャの限界を知らない者が陥る典型的な罠だ。
今日は、HHVMのJIT生成メモリを制御し、いかにして「堅牢かつ高速」な実行環境を構築するか、その深層心理を紐解いていく。
—
1. なぜJITメモリは膨張するのか：アーキテクチャの真実
HHVMのJITは、バイトコードをネイティブなマシンコードに変換し、それを`TC`（Translation Cache）という専用のメモリ領域に格納する。問題は、「多様なコードパス」が生成されるほど、TCは断片化し、肥大化するという点にある。
特に、以下のようなパターンはメモリの無駄遣いを生む温床だ。
- 過剰なポリモーフィズム: 型が確定しない動的な呼び出しが繰り返されると、JITは「ガード（型チェック）」を多重生成し、キャッシュを埋め尽くす。
- 過剰なジェネリクスの展開: 不必要な型パラメータの組み合わせが、個別のマシンコードを生成させる。
2. JITキャッシュを制御する設定の極意
`php.ini`（あるいは `server.ini`）の設定は、運任せにしてはいけない。メモリ消費量を抑えつつパフォーマンスを維持するための、実戦的なチューニングポイントを解説する。
; 1. TCの最大サイズを制限する（デフォルトは無限に近い可能性がある）
; アプリケーションの規模に合わせて物理メモリの10%〜20%を目安に設定する
Eval.JitTranslationCacheSize = 268435456 ; 256MB
; 2. JITの積極性を抑える
; コンパイルのしきい値を調整することで、頻繁に実行されないコードのJIT化を防ぐ
Eval.JitPGO = true ; プロファイル誘導最適化を有効に（必須）
Eval.JitPGOResultThreshold = 1000 ; 実行回数が少ないコードはJITをスキップ
チーフアーキテクトの警告: `JitTranslationCacheSize`を絞りすぎると、JITが頻繁にキャッシュをフラッシュ（破棄）し、再コンパイルのオーバーヘッドでCPUが焼き切れる。監視ツールで `hhvm.jit.tc_size` を常に追跡せよ。
—
3. 「動的」を捨て、「静的」を拾う設計パターン
メモリ消費を抑える最大の武器は、「JITが推論しやすいコードを書く」ことだ。型チェッカーが静的に解決できるコードは、JITにとっても「最適化が容易で無駄なガードを生成しない」コードとなる。
実践：メモリ効率を意識したコンポーネント設計
「何でも受け入れる」インターフェースは、JITに重い負荷をかける。具体的な型を強制し、キャッシュ効率を最大化する設計例を示そう。
<<__ConsistentConstruct>>
abstract class BaseProcessor {
// 型を曖昧にせず、具体的な具象型で扱う
abstract public function process(string $payload): void;
}
final class JsonProcessor extends BaseProcessor {
<<__Override>>
public function process(string $payload): void {
// 静的型システムにより、JITはインライン展開を積極的に行い
// 余計な型ガードを省略できるため、TCメモリの消費が抑えられる
$data = \json_decode($payload, true);
if (!\is_array($data)) return;
// …
}
}
// 呼び出し側
function execute(BaseProcessor $p, string $data): void {
// 抽象クラスへの依存を最小限にし、具象クラスの呼び出しを固定させることで
// JITの「Devirtualization（脱仮想化）」を促進する
$p->process($data);
}
この設計がなぜ美しいのか
1. `final`キーワードの活用: クラスの継承を禁止することで、JITはクラス階層の探索を止める。これは直接的な呼び出し（Direct Call）を可能にし、キャッシュの無駄な生成を防ぐ。
2. 型ヒントの徹底: `string` や `array` などの型を明示することで、JITは「型ガード」というマシンコード上の無駄な条件分岐を省くことができる。
—
4. 現場で今すぐやるべきこと
1. `hhvm.jit.dump_tc_metadata` を活用せよ: 本番環境でメモリが溢れる前に、どの関数が巨大なTCを消費しているかプロファイリングを行うこと。
2. `__Memoize` の乱用に注意: メモ化はメモリを消費する。キャッシュの生存期間と、生成されるキーの種類（ユニークな型）を厳密に管理せよ。
3. 無名関数の多用を控える: 無名関数はクロージャとして個別の型を持たされやすく、JITのキャッシュ戦略を複雑にする。名前付きのクラスメソッドを優先せよ。
最後に：コードは「対話」である
JITは決してブラックボックスではない。我々が書くコードの構造こそが、HHVMが生成するバイナリの設計図だ。メモリを圧迫しているのは、HHVMのせいではない。我々の書いた、最適化を拒むような「緩いコード」のせいなのだ。
「コンパイル時にすべてを解決する」というHackの哲学に立ち返れ。型チェッカーが沈黙する場所には、常にメモリ効率の良い高速なコードが待っている。
健闘を祈る。次回のコードレビューで、君の書いた美しいコードを見ることを楽しみにしている。