HHVMのプロファイルガイド付き最適化（PGO）の深層：実行時の型分布がJITのコード生成に与える影響
テックリードのSaitoだ。コードレビューで「とりあえず動くからよし」というプルリクエストを見かけるたびに、私はこう問いたくなる。
「君は、HHVMがそのコードをどう解釈し、CPU上でどう実行しているか想像したことがあるか？」と。
Hackは厳格な静的型システムを持ち、コンパイル時に多くの型エラーを弾いてくれる。だが、勘違いしてはならない。静的な型定義は、JITコンパイラにとっての「スタートライン」に過ぎないのだ。
真のパフォーマンスを引き出す鍵は、HHVMが稼働中に収集するPGO（Profile-Guided Optimization：プロファイルガイド付き最適化）と、そこで得られる「実行時の型分布（Runtime Type Distribution）」にある。
今回は、HHVMのJITエンジンがランタイムで何を見ているのか、そして我々エンジニアが「JITに愛されるコード」を書くためにどう設計すべきかを、深層から紐解いていこう。
—
1. 静的型システムとJITのギャップ：なぜ「型ヒント」だけでは不十分なのか
Hackのコードベースでは、このように厳格な型定義を行うのが常識だ。
<<____Explicit>>
class OrderProcessor {
public function process(Order $order): PaymentResult {
// …
}
}
型チェッカー（hhvm）はこの記述を見て安心し、ビルドを通す。しかし、HHVMのJITコンパイラ（TC: Translation Cache）にとって、このインターフェイスや基底クラスの指定は「可能性の幅」にすぎない。
もし `Order` クラスに以下のような具象クラスが存在したらどうなるか？
- `StandardOrder`
- `SubscriptionOrder`
- `B2BEnterpriseOrder`
静的にはすべて `Order` 型として扱える。しかし、実際のプロダクション環境における実行時の型分布がどうなっているかがJITの運命を分ける。
- 99%が `StandardOrder` で、残りの1%がその他か？
- それとも、3つの型が綺麗に33%ずつ分散しているか？
この「実行時の偏り（HotnessとPolymorphismの度合い）」こそが、JITが生成する機械語の品質を決定づける。
—
2. PGOのメカニズム：JITはいかにして「高速なパス」を構築するか
HHVMのアーキテクチャにおいて、コードは最初は汎用的なインタープリタまたは低最適化JIT（Translating to TC）で実行される。その過程で、Profiling Translatorが稼働し、以下の情報をプロファイリングデータとして蓄積する。
1. 型フィードバック（Type Feedback）: メソッド呼び出しやプロパティアクセスの際、実際に渡ってきた引数やオブジェクトの具象型は何だったのか。
2. 分岐の偏り（Branch Bias）: `if`文の条件式が、どれほどの確率で真または偽になったのか。
単態化（Monomorphization）とインライン展開の魔法
もしPGOによって「この呼び出し地点（Call Site）を通過するオブジェクトの99%は `StandardOrder` である」と判明した場合、JITは何をするか？
ここで単態化（Monomorphization）と推測的インライン展開（Speculative Inlining）が発動する。
[仮想メソッド呼び出し]
↓ (PGOデータなし)
VMT（仮想メソッドテーブル）を引く動的ディスパッチ (遅い)
↓ (PGOデータあり: 99%が StandardOrder)
[ガード: 型は StandardOrder か？]
├── Yes → インライン展開された最適化コードへ直通！ (高速)
└── No → 低速なフォールバックパスへ落ちる (Megamorphic Deoptimization)
この「ガード（Guard）」を巧みにすり抜けるコードを書くことこそ、ハイパフォーマンスなHackアプリケーション設計の神髄である。
—
3. 実務で陥るアンチパターン：「ポリモーフィズムの罠」
コードの美しさを追求するあまり、過度な抽象化やインターフェイスの乱用を行っていないか？
以下のコードを見てほしい。一見すると非常にオブジェクト指向的で綺麗だが、JITの視点から見ると最悪の構造になり得る。
❌ 悪い設計：過度にポリモーフィックな構造
namespace App\Bad;
interface ICalculator {
public function calculate(float $amount): float;
}
class TaxCalculator implements ICalculator {
public function calculate(float $amount): float { return $amount 0.1; }
}
class DiscountCalculator implements ICalculator {
public function calculate(float $amount): float { return $amount – 500.0; }
}
class OrderPipeline {
// 依存性注入により、様々なICalculatorの具象がランダムに混入する
public function __construct(private Vector
public function run(float $amount): float {
$total = $amount;
foreach ($this->$calculators as $calc) {
// ここでの型が実行時に頻繁に変わる (Megamorphicな状態)
// JITはこの呼び出しをインライン展開できず、VMT経由の遅いディスパッチを強制される
$total = $calc->calculate($total);
}
return $total;
}
}
このループ内での `calculate()` 呼び出しは Megamorphic（多態的） となり、JITは最適化の放棄を余儀なくされ、CPUのパイプラインハザードを引き起こす。
—
4. 【プロダクションコード例】JITのPGO最適化を最大化する堅牢な設計パターン
では、どう設計すべきか？
型分布の偏り（Monomorphicな傾向）を維持しつつ、拡張性と保守性を両立させるパターンを提示しよう。
ここでは、「Union型的な振る舞いをEnumと組み合わせることで、動的なディスパッチをコンパイル時または予測可能な単一分岐へと誘導する設計」を採用する。
<<__STable>>
namespace App\Good;
/
- 計算ロジックの種類を明示するEnum。
- HHVMはこのEnumに基づく分岐を非常に効率的にJITコンパイルできる。
/
enum CalculationType: string {
TAX = ‘tax’;
DISCOUNT = ‘discount’;
SHIPPING = ‘shipping’;
}
<<__ConsistentConstruct>>
final class CalculationStep {
public function __construct(
public CalculationType $type,
public float $value,
) {}
}
/
- 堅牢で、かつJITのPGOが最大限に最適化（単態化・インライン展開）しやすいパイプライン
/
final class OptimizedOrderPipeline {
public function __construct(
private vec
) {}
/
- 実行時の型分布をシンプルに保ち、JITのガードを安定させる。
/
public function execute(float $initialAmount): float {
$amount = $initialAmount;
// vec
foreach ($this->steps as $step) {
// switch 文の分岐は、PGOにより「どのStepTypeが頻出するか」が学習され、
// ホットパス（よく使われる分岐）がCPUの予測バッファに最適に配置される。
$amount = switch ($step->type) {
CalculationType::TAX => $this->applyTax($amount, $step->value),
CalculationType::DISCOUNT => $this->applyDiscount($amount, $step->value),
CalculationType::SHIPPING => $this->applyShipping($amount, $step->value),
};
}
return $amount;
}
<<__AlwaysInline>>
private function applyTax(float $amount, float $rate): float {
// __AlwaysInline 属性により、JITに対して強制的なインライン展開をヒントとして与える
// （※過剰使用は禁物だが、ホットパスの小さな関数には極めて有効）
return $amount (1.0 + $rate);
}
<<__AlwaysInline>>
private function applyDiscount(float $amount, float $discount): float {
return max(0.0, $amount – $discount);
}
<<__AlwaysInline>>
private function applyShipping(float $amount, float $fee): float {
return $amount + $fee;
}
}
この設計がプロダクションで最強である理由
1. メガモーフィズムの排除:
インターフェイスを介した動的メソッド呼び出し（`$calc->calculate()`）を排除し、単一のクラス（`OptimizedOrderPipeline`）内のプライベートメソッドへ集約している。これにより、JITはメソッド呼び出しを完全にインライン展開しやすくなる。
2. Enumベースの予測可能な分岐:
`switch` 式を用いることで、HHVMのPGOは「どのケースが日常的に実行されているか」を正確にプロファイルし、CPUの分岐予測精度を極限まで高める。
3. データ構造の純化（`vec
Hackのシームレスなコレクション型（`vec`）を使用することで、HHVMのヒープ管理とGCの負荷を最小限に抑えつつ、キャッシュヒット率の高い連続したメモリレイアウトを実現している。
—
5. テックリードからの実務アドバイス
コードレビューで「動的すぎるコード」を見つけたら、こう指摘してほしい。
「その抽象化、本当に実行時の多様性（Polymorphism）が必要か？ もし特定の型に偏るのであれば、JITのPGOが最適化しやすいフラットな構造に書き換えてくれ」と。
静的型チェッカーは「コードが正しいこと」を証明してくれるが、「コードが速いこと」を保証してくれるのは、JITと対話できるあなたの設計センスだけだ。
HHVMの内部挙動——JITが型フィードバックを受け取り、ガードを張り、機械語を最適化するプロセス——を脳内にトレースしながらコードを書く。それこそが、大規模トラフィックを支える真のHackエンジニアの条件である。