HHVMのJITを飼いならせ：投機的最適化の「脱落」を防ぐ静的設計の極意
Hackという言語は、単なるPHPの進化系ではない。HHVMという猛獣を制御するための、極めて精密な外科手術用メスだ。
多くのエンジニアが「HHVMは速い」と信じている。しかし、その速度はJIT（Just-In-Time）コンパイラが「お前のコードをどれだけ信頼できるか」に依存している。もし君のコードがJITの予測を裏切り続ければ、HHVMはデオプティマイゼーション（Deoptimization）という名の断罪を下す。一度生成した最適化済みコードを破棄し、低速なインタプリタモードへフォールバックするのだ。
今日は、その「信頼の崩壊」を防ぎ、JITを最強の味方にするためのアーキテクチャ設計について話そう。
—
1. なぜJITは「裏切り」を検知するのか
HHVMのJITは、プロファイル・ガイド・オプティミゼーション（PGO）を行っている。実行時に「この変数は常にこの型だ」「このクラスは継承されていない」という仮定（Speculation）を立て、その仮定に基づいた超高速なマシンコードを生成する。
問題は、「コードが柔軟すぎること」だ。
例えば、`mixed` 型を多用したり、一つの関数が多様すぎる型の引数を受け取ったりすると、JITは「この最適化は通用しない」と判断する。これがデオプティマイゼーションの引き金だ。一度引き金が引かれると、JITはガード（Guard）と呼ばれるチェック命令をコード中に大量に挿入し始め、パフォーマンスは崖を転げ落ちる。
2. 実務で陥る「デオプティマイゼーション」の罠
よくある「最悪なパターン」を見てみよう。
アンチパターン：型を曖昧にする「柔軟性」
// 悪い設計：何でも受け入れる「親切」はJITへの「背信」
function processData(mixed $data): void {
// HHVMはここで$dataの型を予測できない。
// 実行のたびに型チェックのガードが入り、JITは最適化を諦める。
if ($data is int) {
// …
} else if ($data is string) {
// …
}
}
回避策：ジェネリクスと具体的型による「静的契約」
JITが最も好むのは、「型が完全に静的に決定している」状態だ。
// 良い設計：ジェネリクスで型を固定し、JITにヒントを与える
interface Processor
public function handle(T $data): void;
}
class IntProcessor implements Processor
public function handle(int $data): void {
// ここでの演算は直接CPU命令に変換され、ガードは最小限で済む
}
}
—
3. プロダクションコードにおける「JITフレンドリー」な設計パターン
非同期API連携や重厚なドメインロジックを組む際、以下の3つの鉄則を守れ。
① `shape` を活用し、構造を固定する
連想配列（`dict`）は便利だが、キーが動的に変わるものはJIT泣かせだ。構造が固定されているなら、必ず `shape` を使え。
type UserProfile = shape(
‘id’ => int,
‘email’ => string,
‘is_active’ => bool,
);
// shapeはメモリレイアウトが予測可能であり、JITはオフセットを直接計算できる
function updateStatus(UserProfile $profile): void {
if ($profile[‘is_active’]) {
// …
}
}
② クラスの `final` 宣言を怠るな
HHVMにとって、クラスが継承可能であることは「メソッド呼び出しがオーバーライドされるかもしれない」という不確定要素を意味する。`final` をつけることで、JITは「このメソッドは絶対に変更されない」と確信し、インライン展開（Inlining）を躊躇なく行う。
// 呼び出し側でクラスがfinalであれば、メソッド呼び出しは直接ジャンプに置き換わる
final class PaymentGateway {
public function authorize(int $amount): bool {
return $amount > 0;
}
}
③ `vec` と `dict` の型を明示する
`varray` や `darray` の名残で `vec
—
4. 最後に：コードは「契約」である
JITコンパイラは、君の書いたコードを「統計的に最も効率的な形」に翻訳しようと必死に働いている。その努力を無にするのは、型を曖昧にし、継承を乱用するプログラマの怠慢だ。
- 型を厳格に定義することは、単なるデバッグの補助ではない。
- 構造を固定することは、単なる設計の規律ではない。
これらはすべて、マシンに対する強力なヒント（Hinting）なのだ。
君たちが書くコードが、HHVMという強大なエンジンをただの重石にするのか、それとも光速の演算機に変えるのか。その分かれ道は、型定義の一つひとつの鋭さにある。
コードレビューの際、`mixed` や `dynamic` が目に留まったら、自分に問いかけろ。「これは、JITの投機的最適化を妨げる『負の遺産』になっていないか？」と。
さあ、コードを書いてくれ。JITが驚くほど、静的で、美しく、冷徹なコードを。