HHVMのJITメトリクスを読み解く：perfツールを用いたボトルネック分析
ランタイムの深淵を覗く覚悟はあるか。
我々が日常的に記述するHackの厳格な型は、HHVM（HipHop Virtual Machine）の圧倒的なスループットと引き換えに成立している。PHPの動的な泥沼から脱却し、完全な静的型付けと非同期処理（Async）の恩恵を受けるHackコードは、最終的にHHVMのトランスレータ（TC: Translation Cache）によってx86-64ネイティブコードへと変換される。
しかし、JITコンパイルが万能であるという幻想は捨てなければならない。高度な多態性（Polymorphism）、型ガードの破綻、そしてCPUキャッシュの汚染は、最高峰のJITエンジンであっても無慈悲にパフォーマンスを殺す。
本稿では、Linuxの基盤である `perf` ツールを駆使し、HHVMのJIT実行時におけるCPUサイクル、I-Cache（命令キャッシュ）ミス、そしてTCの挙動を極限まで暴き出す手法を解説する。甘い最適化の神話はここで終わりだ。
—
1. HHVM JITアーキテクチャとハードウェアの現実
HHVMのJITパイプラインは、おおむね以下のフェーズで構成されている。
1. Unit Loader: Hackのbytecode（HHBC）を読み込む。
2. Interp / Profiler: 初回実行時はインタプリタで動作し、型情報やプロファイルデータを収集する。
3. Region Selector (PGO): プロファイル誘導最適化（Profile-Guided Optimization）に基づき、ホットスポットを特定する。
4. Translator (tc-amd64): 最適化されたネイティブマシンコードを Translation Cache (TC) に生成する。
ここでシニアエンジニアが直面する最大の敵は 「TCの肥大化によるI-Cacheスラッシング」 である。無駄なジェネリクスや過度な動的ディスパッチは、JITに膨大なガード命令（Type Guard）を生成させ、CPUの命令キャッシュ（L1i / L2）を溢れさせる。結果として、CPUはメモリからのフェッチ待ち（Stall）で飢餓状態に陥る。
このハードウェアレベルの悲鳴を観測するのが、他ならぬ `perf` である。
—
2. ターゲットとなるHackコードの構造
まずは、意図的にJITに負荷をかけるHackコードを用意しよう。以下のコードは、緩い型付けの模倣や過剰なポリモーフィズムが、いかにJITの型ガードを爆発させるかを示す縮図である。
// @hh-strict
namespace HackPerfLab;
interface IProcessor {
public function execute(int $x): int;
}
class FastProcessor implements IProcessor {
public function public_int $value;
public function __construct(int $v) {
$this->value = $v;
}
public function execute(int $x): int {
// 厳格な型による単純計算：JITにとっての理想郷
return $x $this->value;
}
}
class DynamicPayloadProcessor implements IProcessor {
public function __construct(private mixed $payload) {}
public function execute(int $x): int {
// mixedからのアンボックスと型チェックの強制：JITの悪夢
if ($this->payload is int) {
return $x + $this->payload;
}
return $x;
}
}
class BenchmarkRunner {
public static function run(int $iterations, IProcessor $processor): int {
$acc = 0;
for ($i = 0; $i < $iterations; $i++) {
$acc += $processor->execute($i);
}
return $acc;
}
}
<<__EntryPoint>>
function main(): void {
$p1 = new FastProcessor(42);
$p2 = new DynamicPayloadProcessor(100);
$total = 0;
// ホットループの形成
for ($i = 0; $i < 1000000; $i++) {
$total += BenchmarkRunner::run(100, $p1);
$total += BenchmarkRunner::run(100, $p2);
}
\var_dump($total);
}
このコードにおいて、`BenchmarkRunner::run` は2種類の異なるクラス（`FastProcessor`, `DynamicPayloadProcessor`）を受け取る。単態性（Monomorphic）を期待していたJITは、ここでインラインキャッシュ（Inline Cache）のミスを引き起こし、メガモルフィックなディスパッチまたは高コストな型ガードの再評価を強いられる。
---
3. `perf` によるHHVMランタイムのプロファイリング実践
では、実際にLinux環境下でHHVMプロセスを `perf` で監視し、CPUのボトルネックを特定する。
ステップ 1: デバッグシンボルの確保とHHVMの起動
正確なシンボル解決（コールスタックの復元）を行うため、HHVMはフレームポインタを保持した状態でビルドされていなければならない（`-fno-omit-frame-pointer`）。
以下のコマンドで、対象のHackスクリプトを実行しながら `perf record` を走らせる。
CPUサイクル、L1命令キャッシュミス、分岐予測ミスを同時にキャプチャする
perf record -e cycles,L1-icache-load-misses,branch-misses -F 9999 — \
hhvm -v Eval.JIT=true main.hack
- `-e cycles,L1-icache-load-misses,branch-misses`: JITの効率を測定する上で最も重要な3つのハードウェアカウンタを指定。
- `-F 9999`: サンプリング周波数（Hz）。
- `hhvm -v Eval.JIT=true`: JITを有効化した状態で実行。
—
ステップ 2: データの解析とボトルネックの特定
記録された `perf.data` を解析する。
perf report –no-children –sort=comm,dso,symbol
出力結果のなかに、見慣れないアセンブリ領域やHHVMの内部関数が現れるはずだ。ここで注目すべきは、ユーザーコードのシンボル名だけでなく、HHVMのTC領域を示す匿名メモリマップ（`[unknown]` や `tc-amd64` に類似する領域）の占有率である。
さらに、キャッシュミスの発生源を深掘りする。
perf annotate –symbol=”HackPerfLab\\BenchmarkRunner::run”
もしここで `L1-icache-load-misses` が特定の分岐命令（JITが生成した型ガードの失敗に伴うスタブへのジャンプ）に集中している場合、それは「ポリモーフィズムによるコードの肥大化とキャッシュ汚染」が発生している明白な証拠である。
—
4. JITメトリクスから読み解く最適化の極意
`perf` の結果から得られた知見を、コードのアーキテクチャにフィードバックする。シニアエンジニアが取るべき対策は以下の通りだ。
A. インラインキャッシュの単態化 (Monomorphization)
先ほどのコードでは、`BenchmarkRunner::run` が `IProcessor` インターフェースを受け取っていたため、JITは呼び出し先を特定できず、ガード（Guard）を生成した。これを明示的な具象型の使用や、ジェネリクスの活用（Hackの強力な型システム）によって単態化する。
// 修正版：ジェネリクスを用いてコンパイル時に型を確定させ、JITに完全なインライン展開を許可する
class BenchmarkRunnerGeneric
public static function run(int $iterations, T $processor): int {
$acc = 0;
for ($i = 0; $i < $iterations; $i++) {
$acc += $processor->execute($i);
}
return $acc;
}
}
これにより、JITは動的なディスパッチを完全に排除し、`execute` メソッドの本体を呼び出し元に直接インライン展開（Inlining）できる。結果として、TCのコードサイズは縮小し、`L1-icache-load-misses` は劇的に低下する。
B. `mixed` 型の徹底的な排除
`DynamicPayloadProcessor` で見られた `mixed $payload` に対する `is int` チェックは、JITに対して「型が変動する可能性」を常に意識させる。Hackの恩恵を最大化するためには、可能な限りプリミティブ型や厳格なシェイプ（Shape）、あるいは代数的データ構造を設計に組み込み、ランタイムの型推論（Type Inference）の負荷をゼロに近づけることだ。
—
5. チーフアーキテクトからの提言
JITコンパイラは魔法の箱ではない。それはハードウェアの物理的制約（CPUキャッシュの容量、分岐予測器のバッファ、メモリ帯域）の上で泥臭く最適化を行うエンジニアリングの結晶にすぎない。
Hackの静的型チェッカー（hh_client）がコンパイルエラーを防ぐのは第一歩に過ぎず、本番環境のスケールにおいては、HHVMが生成するネイティブコードの挙動を `perf` で見通す視点こそが、真のハイパフォーマンスシステムを構築するエンジニアの条件である。
コードの構造がハードウェアのキャッシュラインにどう映し出されているか——それを想像できないコードに、最適化の未来はない。常に計測し、ランタイムの息吹を感じ取れ。