HHVMの深淵：JITトレースが「魂」を持つ瞬間、そして消えゆく静寂
Hackのコードを書く際、君たちは「書いたコードがどう動くか」を意識しているだろうか？ 単なるPHPの延長として捉えているなら、それは重大な損失だ。HHVMは単なるインタープリタではない。これは実行時に最適化を繰り返す、生き物のようなエンジンだ。
今日は、HHVMの心臓部である「JITトレース（Trace）」のライフサイクルを解剖する。なぜ君たちのコードが時に爆速になり、時にパフォーマンスの深淵に沈むのか、その理由を明かそう。
—
1. JITトレースのライフサイクル：覚醒から灰燼へ
HHVMのJITは、コードを単に翻訳するのではない。「ホットパス（実行頻度の高い経路）」を特定し、それを抽象構文木からマシン語（x64/ARM64）へ昇華させる。
Phase 1: 観測とプロファイリング（Profiling）
HHVMは起動直後、すべてのコードをバイトコード（HHBC）で実行する。ここでTC（Translation Cache）の構築は始まらない。最初は、どの関数、どのループが「熱い」のかを監視する。これがプロファイル段階だ。
Phase 2: トレースの構築（Trace Building）
一定の閾値（Threshold）を超えると、HHVMは実行パスを「トレース」として記録する。
- Linearization: 分岐を含めて、予測される実行パスを一本の直線的なマシン語の塊にフラット化する。
- Type Guarding: ここがHackの真骨頂だ。静的型システムのおかげで、HHVMは「この変数は常にintである」という前提でマシン語を生成できる。
Phase 3: マシン語への変換（Translation）
最適化されたIR（中間表現）が、JITコンパイラによってマシン語に翻訳され、メモリ上の「コードキャッシュ」に書き込まれる。この瞬間、君のロジックはCPU直結の極致へと変貌する。
Phase 4: 破棄（Eviction / Decommissioning）
メモリは有限だ。トレースが古くなったり、コードの変更（再デプロイ）で無効化されると、HHVMは容赦なくそれを破棄する。この「キャッシュの再構築」こそが、デプロイ直後のパフォーマンス低下の正体だ。
—
2. 現場で「バグを避け、速度を殺さない」設計パターン
トレースのライフサイクルを意識すれば、コードは自然と洗練される。特に、「型の不確実性（Type Instability）」を排除することが、JITを効率化する鍵だ。
アンチパターン：トレースを汚染する「多態性の過剰」
以下のようなコードは、JITのトレースを分断し、最適化を無効化する最悪の例だ。
// 悪い例：型が頻繁に入れ替わることで、JITは複数のトレースを生成せざるを得ない
function process(mixed $data): void {
// $dataがintやstring、あるいは複雑なオブジェクトに頻繁に入れ替わると、
// JITは「ガード（型チェック）」を大量に生成し、トレースが破綻する
if ($data is int) { / … / }
else if ($data is string) { / … / }
}
推奨パターン：ShapeとGenericsによる「静的解決」
JITが最も好むのは、メモリレイアウトが確定していることだ。
/
- 良い例：Shapeで構造を固定し、型推論を助ける。
- これにより、JITはプロパティへのオフセットを固定値としてマシン語に埋め込める。
/
type TUserData = shape(
‘id’ => int,
‘name’ => string,
);
function processUser(TUserData $user): int {
// コンパイラは$user[‘id’]のメモリアドレスを確定できるため、
// 高速なレジスタアクセスへ最適化される
return $user[‘id’] 1024;
}
—
3. チーフアーキテクトからの助言：プロダクションの現場で
君たちが明日からすぐやるべきは、「トレースを分断させない」ことだ。
1. Strict Typingを強制せよ: `<<__Strict>>` は単なるコーディング規約ではない。HHVMに対する「この型は絶対に変わらない」という契約だ。契約が守られている限り、HHVMはガード（型確認の命令）を省略し、爆速のコードを吐き出す。
2. 巨大な関数を避けよ: 巨大な関数はJITの解析コストを跳ね上げ、トレースの「質」を下げる。適度な粒度で関数を分割すれば、HHVMはホットパスをより鋭利に削り出すことができる。
3. プロファイラと対話せよ: `hhvm.jit_profile_threshold` や `hhvm.jit_a_size` などの設定を追いかける前に、まずは `Xdebug` ではなく `perf` や `VTune` でCPUの命令パイプラインを可視化せよ。
最後に
HHVMのJITは、君が書いたコードの「意図」を読み取ろうと必死に足掻いている。君が曖昧な型定義をし、動的な振る舞いに逃げれば逃げるほど、JITはガード命令の山に埋もれ、本来の性能を発揮できなくなる。
Hackを使うということは、マシンの挙動までを設計図に組み込むということだ。
君の書く一行が、CPUのパイプラインをどう駆け抜けるか。それを想像できる者が、真のシステムエンジニアである。
さあ、コードを開け。最適化の余地は、まだそこにあるはずだ。