HHVMのJITがメモリを喰らい尽くす前に――コード生成の「深淵」を制御する技術
こんにちは。Hackの深淵へようこそ。
大規模なHackのコードベースを運用していると、ある日突然、HHVMがメモリの崖っぷちに立たされることがあります。原因は明白。「JIT（Just-In-Time）コンパイラが生成するマシン語が、メモリを食い尽くしている」のです。
初学者の皆さんは「コードを書けば動く」と思っているかもしれませんが、裏側ではHHVMが一生懸命、皆さんのHackコードをCPUが理解できる「生の命令」に翻訳しています。今日は、このJITのメモリ消費を制御し、大規模なアプリケーションを安定させるための「職人の知恵」を授けます。
—
1. なぜJITはメモリを消費するのか？
HHVMのJITは、実行時にバイトコードをx64やARM64のマシン語へ変換します。この変換されたコードは「コードキャッシュ」と呼ばれるメモリ領域に格納されます。
想像してみてください。関数が呼ばれるたびに、CPU用の命令セットがメモリ上に「配置」されていくわけです。大規模なプロジェクトでは、このコードキャッシュが肥大化し、システム全体のメモリを圧迫します。これを制御しないと、OSからメモリ不足でプロセスを殺される（OOM Killerの餌食になる）ことになります。
イメージ図：コードキャッシュの構造
[ HHVM Process Memory ]
|———————–|
| HHVM Engine (Base) |
|———————–|
| Heap (Data) | <--- 変数やオブジェクト
|-----------------------|
| Code Cache (JIT) | <--- ★ここが肥大化の主犯！
| (Machine Code) |
|-----------------------|
---
2. メモリを制御する「魔法のスイッチ」
HHVMには、JITの暴走を防ぐための設定がいくつか用意されています。`php.ini`（または`server.ini`）で設定するこれらのパラメータが、私たちの命綱です。
重要な設定パラメータ
- `eval.jit_code_cache_size`:
コードキャッシュの最大サイズを制限します。デフォルトのままだと、大規模アプリでは足りなくなるか、逆に大きすぎてメモリを食いつぶします。
- `eval.jit_max_translated_functions`:
JITコンパイルされる関数の最大数を制限します。使用頻度の低い関数をJIT対象から外すことで、メモリを節約します。
; コードキャッシュを256MBに制限する例
eval.jit_code_cache_size = 268435456
; JIT対象の関数を絞り、メモリ消費を抑制する
eval.jit_max_translated_functions = 10000
—
3. コード生成を最適化する「書き方」のコツ
設定だけでなく、コードそのものを「JITに優しい」書き方にすることも重要です。
極端なポリモーフィズムを避ける
Hackの型システムは強力ですが、あまりに複雑なジェネリクスや不透明な型を多用すると、JITは「どの型が来るか予測できない」と判断し、汎用的すぎる（＝メモリを食う）マシン語を生成してしまいます。
ダメな例（JITが迷子になる）：
function process(mixed $input): void {
// $inputの型が確定しないため、JITは全パターンを想定したコードを生成しようとします
// これがメモリを圧迫します
echo (string)$input;
}
良い例（型を明確にする）：
function process(string $input): void {
// 型が確定していれば、JITは最小限のマシン語を出力できます
echo $input;
}
—
4. 陥りやすい罠：静的型システムとの関係
「静的型システムがあるから、JITは楽をしているはずだ」と思っていませんか？実は逆です。
型が曖昧だと、HHVMは実行時チェック（Type Guard）をマシン語の中に大量に埋め込みます。このチェック処理自体が、コードキャッシュを膨らませる原因になります。
初心者がやりがちなミス：
- 不要な `is` チェックの連発: ループの中で毎回型チェックを行うと、JITはそれをすべて機械語に展開します。型定義を正しく行い、推論に任せるのが「Hackの作法」です。
—
先輩からのアドバイス：どうやって監視するか？
最後に、今の状況が健康かどうかを知る方法を教えます。HHVMには `admin server` という強力なツールがあります。
実行中のHHVMの統計を確認する
curl http://localhost:8088/hhvm.stats
ここで `jit.code_cache_usage` を確認してください。これが上限に近いようなら、メモリの限界が迫っています。
—
まとめ
1. JITは「メモリと引き換えに速度を買う」技術であることを理解する。
2. `eval.jit_code_cache_size` で物理的な限界を設ける。
3. `mixed` 型を避け、明確な型定義でJITに「最適化のヒント」を与える。
Hackは、ただ動くコードを書くだけの言語ではありません。マシンがどう動き、メモリをどう使うかを意識できる「アーキテクト」のための言語です。ここをマスターすれば、皆さんはもう初学者ではありません。
さあ、次はどんな最適化に挑みますか？応援していますよ。