【実務・中級編】HHVMのJITメトリクスを読み解く：perfツールを用いたボトルネック分析 – Hack言語コア・静的型システムとHHVMのアーキテクチャ解析バイブル

HHVMの深淵を覗く：perfツールでJITメトリクスをハックし、極限のパフォーマンスを引き出す法

チームの皆さん、コードレビューお疲れ様です。
今回のテーマは、我々が日常的に頼っているHack言語を支える心臓部、HHVM（HipHop Virtual Machine）のJITコンパイル構造と、Linuxの`perf`ツールを用いたボトルネック分析です。

「Hackは静的型システムのおかげで安全だし、HHVMが勝速くしてくれるから大丈夫」――そう思っていませんか？
確かにHHVMは、独自のTC（Translation Cache：ネイティブ機械語キャッシュ）と強力なプロファイル駆動型JIT（Profile-Guided JIT）を備えた化け物のような仮想マシンです。しかし、型の境界があいまいなコードや、JITの予測を裏切るポリモーフィックなディスパッチを書いた瞬間、HHVMはネイティブ実行から無慈悲なインタープリタ（あるいは高コストな再コンパイル）へとフォールバックします。

今日は、プロファイラの向こう側にある現実、すなわちCPUのL1/L2キャッシュミスや、JITトレースの断片化を`perf`で丸裸にし、「なぜその書き込みがボトルネックになるのか」「どう設計すればJITが最速のネイティブコードを生成し続けるのか」を、実務のコードと共にお見せします。

—

1. HHVMとJITの裏側：なぜコードは「遅く」なるのか？

HHVMの実行モデルを復習しましょう。HackコードはまずBytecode（HBC）にコンパイルされ、HHVMの仮想マシン上で実行されます。実行頻度が高いホットスポット（Hot Spot）は、実行時プロファイル情報に基づき、TC（Translation Cache）上で x86-64 などのネイティブ機械語へとJITコンパイルされます。

ここで意識すべきは、「JITコンパイラが最適化しやすいコードを書く」ということです。

JITの敵：ポリモーフィズムと型不安定性

HHVMのJITは、型の揺らぎ（Type Instability）を嫌います。例えば、ある関数が常に特定の形状のオブジェクトやプリミティブを受け取る場合、JITはインラインキャッシュ（Inline Caching）や単相的（Monomorphic）なディスパッチを展開し、直にレジスタを叩くコードを生成します。
しかし、引数の型が頻繁に変わる（多相的 / Polymorphic）と、JITはガーディアン（型チェックの分岐）を大量に挿入せざるを得なくなり、最悪の場合はトレースが破綻してTCから追い出されます（TC Miss / Translation eviction）。

この「JITの息切れ」を検知するために、Linuxカーネルのパフォーマンス解析スイートである `perf` を使います。

—

2. 実践：`perf` を用いたHHVMのJITメトリクス分析

プロダクション環境でHHVMの挙動をプロファイリングする際、単なるCPU使用率（`top`や`htop`）を見ていても意味がありません。我々が見るべきは以下のハードウェアカウンタです。

1. `cycles` / `instructions` (IPC): 命令実行効率。
2. `cache-misses`: L3キャッシュミス。メモリ帯域の圧迫。
3. `branch-misses`: 分岐予測ミス。JITが生成したガード命令の失敗を示唆。

ステップ1: JIT領域を含むシンボル情報の有効化

HHVMは実行時にコードを生成するため、デフォルトのままだと `perf report` はメモリアドレスしか表示せず、どのHack関数がボトルネックになっているか分かりません。
これを解決するため、HHVMの設定（`server.ini` またはコマンドライン）でJITプロファイル用のperfmapを有効にします。

; php.ini / server.ini の設定例
hhvm.jit.profile_interp_requests = 0
hhvm.jit.perf_events_map = true

ステップ2: `perf record` によるサンプリング

負荷試験（`wrk`や`ab`など）をかけながら、HHVMプロセスに対して `perf` をアタッチします。

PIDを指定して、CPUサイクル、分岐ミス、キャッシュミスを記録（周波数99Hzでサンプリング）
sudo perf record -F 99 -e cycles,branch-misses,cache-misses -p $(pgrep -n hhvm) — sleep 30

ステップ3: ボトルネックの特定 (`perf report`)

記録されたデータをアナライズします。

sudo perf report –stdio –no-children

ここで、シンボル名に `HPHP::Transl` やJIT生成コード特有のものが大量に出現している場合、あるいは `branch-misses` の比率が異常に高い場合、あなたの書いたHackコードのどこかに「JITにとって悪夢のような動的挙動」が潜んでいます。

—

3. 堅牢でJITフレンドリーなHackコード設計

では、どういうコードがJITを喜ばせ、パフォーマンスを極限まで引き上げるのでしょうか？
実務の非同期API連携やドメインロジックを想定した、「バグが起きず、かつHHVMの最適化を最大限に引き出す美しいプロダクションコード」を提示します。

以下のコードは、厳格な型定義（`strict`）を維持しつつ、ポリモーフィズムを排除してJITのインライン展開を促す設計パターンです。

namespace HackPerformance\Metrics;

堅牢なデータ構造と、JIT最適化を考慮したメトリクス集計プロセッサ。
動的な配列アクセスを避け、ShapeとGenericsを駆使して型を完全に静的に確定させる。

/
type TMetricPayload = shape(
‘metric_id’ => string,
‘value’ => float,
‘timestamp’ => int,
);

class MetricProcessor {
// 内部キャッシュ：型の揺らぎを防ぐため、コンテナの型を厳格に固定する
private Vector $buffer;

public function __construct() {
$this->buffer = Vector {};
}

データを投入する。
引数の型を厳格に絞ることで、JITはディスパッチコストをゼロ（直インライン化）にできる。

/
public function ingest(TMetricPayload $payload): void {
// HHVMのVectorに対する操作は、型が完全に静的な場合に最も効率的なネイティブコードにコンパイルされる
$this->buffer->add($payload);
}

集計処理：
クロージャ内で動的な変数参照や配列の動的キー生成を行わず、
JITの予測可能性を最大化するループ構造を採用。

/
public async Task> computeAveragesAsync(): Awaitable> {
if ($this->buffer->isEmpty()) {
return dict[];
}

$sums = dict[];
$counts = dict[];

// 厳密に型付けされたイテレーション
foreach ($this->buffer as $item) {
$id = $item[‘metric_id’];
$val = $item[‘value’];

if (!Shapes::keyExists($sums, $id)) {
$sums[$id] = 0.0;
$counts[$id] = 0;
}

$sums[$id] += $val;
$counts[$id]++;
}

$result = dict[];
foreach ($sums as $id => $total) {
$count = $counts[$id];
// ゼロ除算防護と、型安全な計算
$result[$id] = $count > 0 ? $total / (float)$count : 0.0;
}

// 非同期コンテキストのシミュレーション（I/Oバウンドな後続処理を想定）
await RescheduleWaitHandle::create(RescheduleWaitHandle::QUEUE_DEFAULT, 0);

return $result;
}
}

コードレビュー：なぜこの実装が優れているのか？

1. `<>` と Shape の徹底:
動的な `array`（PHPのassociative arrayの残骸であるハッシュマップ）ではなく、`shape` を用いることで、キーの存在と値の型がコンパイル時に完全に決定されます。これにより、HHVMはプロパティアクセスのためのハッシュルックアップをインライン化し、直接メモリオフセットアクセス（ネイティブの構造体アクセスに近い速度）にコンパイルできます。
2. ポリモーフィズムの排除:
メソッドの引数に抽象度の高い `mixed` や基底クラスではなく、具体的な `TMetricPayload` 型を指定しています。JITコンパイラは型ガード（「本当にこの型か？」のチェック）を省略でき、TC内のコードが肥大化（Bloat）しません。
3. `Vector` コンテナの適切な利用:
HHVMの `Vector` や `Map` などのcollectionsは、PHP標準配列よりもメモリ効率が高く、JITがイテレーションをアンロール（Unroll）しやすいため、CPUキャッシュミスを劇的に削減します。

—

4. チーフアーキテクトからの提言

`perf` を使ったチューニングを始めると、多くのエンジニアは「どの関数が遅いか」というミクロな視点にとらわれがちです。しかし、HHVM環境における真のボトルネックは、大抵の場合「コードの動的すぎる構造によるJITのキャッシュミス（TC Eviction）」にあります。

リフレクションの多用
クロージャ内での動的な型変更
巨大すぎるメソッド（JITのインライン展開サイズ制限を超えるもの）

これらはすべて、HHVMに無駄なネイティブコード生成を強め、CPUの命令キャッシュ（i-cache）を汚染します。

「型を極めよ。さすればJITは汝に最速の翼を与えるだろう。」

Hackの静的型システムは単なるバグ防護壁ではありません。それはHHVMという巨大なJITエンジンを調教するための、唯一にして最強のコントロールレバーなのです。
次回のパフォーマンスレビューでは、ぜひ `perf` のカウンタを片手に、あなたのコードが奏でるネイティブ機械語のハーモニーを確認してみてください。それでは、健闘を祈る。