HHVMの深淵：JITコンパイルにおける「定数畳み込み」の限界と最適化の境界線
HackのJITコンパイラであるHHVMの内部構造は、単なるコード変換器ではない。それは、実行時の型情報（Runtime Type Information: RTTI）を武器に、動的言語の柔軟性と静的言語のパフォーマンスを融合させる「適応型最適化エンジン」である。
多くのシニアエンジニアが、定数畳み込み（Constant Folding）を「魔法」のように捉えているが、それは間違いだ。JITが何を行い、何を決して行わないのか。その境界線を知る者だけが、CPUキャッシュとレジスタを支配できる。
—
1. 静的コンパイルとJITの「時間軸」の断絶
コンパイラ最適化の基本原則は「計算を可能な限り左側（コンパイル時）へ寄せること」だ。しかし、HHVMにおいて、コードが書かれた瞬間は「コンパイル時」ではない。HHVMはRepo Authoritativeモードであっても、プロファイルデータに基づいた再最適化を行う。
ここで重要なのは、「コンパイル時定数」と「実行時定数」を混同してはならないということだ。
- コンパイル時定数: `const` や `define`。HHVMはこれらをHHBC（HipHop Bytecode）生成時に即値として埋め込める。
- 実行時定数: プログラムの実行初期に一度だけ決定され、以降変化しない値。
JITは「実行時定数」を追跡し、定数畳み込みを試みるが、ここにはメモリの「参照ポインタの解決」というコストが常に付き纏う。
2. JITが「定数」と見なさないコードの罠
以下のコードを見てほしい。一見、定数のように見えるが、JITにとっては最適化が極めて困難なケースだ。
namespace OptimizationLabs;
class Config {
// 外部からの注入、または複雑な演算を伴う定数
public static string $apiEndpoint = $_ENV[‘API_URL’] ?? ‘https://api.default.com’;
}
function fetch_data(): void {
// ここでの$urlは、JITから見れば「ループ毎に書き換わる可能性があるメモリ上の値」として解釈される
// 実行時定数として安定していても、静的解析の境界を越えているためレジスタに固定されない
$url = Config::$apiEndpoint;
for ($i = 0; $i < 1000; $i++) { // 毎回Configクラスの静的プロパティテーブルをルックアップするコストが発生する log($url); } }
なぜこれが最適化されないのか？
HHVMのJITエンジンは、特定のクラスの静的プロパティが「イミュータブルである」という保証を、型システムだけでは完全に確信できない場合がある。特に、`$_ENV`のようなグローバル状態に依存する場合、JITは「ガード（守護条件）」を生成し、プロパティが変化していないかをチェックし続ける必要がある。この「チェックのコスト」が、定数畳み込みによる恩恵を相殺してしまう。
3. 「レジスタ・ポジティブ」なコードを書くための戦略
最適化を強制する（Force-optimize）ためには、JITに「この値はプログラム実行中、二度と変化しない」という強いヒントを与える必要がある。
戦略：アサーションと定数化によるガードの回避
最も強力なのは、型チェッカーとJITの両方に、値の不変性を明示することだ。
function optimized_loop(): void {
// 実行時定数をローカルスコープにキャプチャする
// これにより、ループ内でのクラスプロパティ・アクセスを排除する
$url = Config::$apiEndpoint;
// 実行時に不変であることを保証するアサーション
invariant($url !== ”, ‘Endpoint must be configured’);
// HHVMのJITは、この時点で$urlをレジスタに保持し、
// ループ内でのメモリ読み出しを省略する可能性が飛躍的に高まる
for ($i = 0; $i < 1000; $i++) {
process_with_static_url($url);
}
}
4. 内部アーキテクチャの視点：なぜ「静的型」が最適化を加速させるのか
HHVMのJITコンパイラ（特に`IR`層）は、型情報が詳細であればあるほど、生成されるマシンコードの「ガード」を削除できる。
1. 型推論の不完全性: 型が曖昧だと、JITは「もし整数なら加算、もし文字列なら結合」という条件分岐（Guard）を生成する。
2. 型情報の徹底: `string` や `int` などの具象型を明示することで、JITはガード命令をバイパスし、直接CPUの`ADD`や`MOV`命令を生成できる。
極限の知見:
「定数畳み込み」はコードの見た目ではなく、「データフローの断絶」をどれだけ減らせるかにかかっている。関数呼び出しや動的アクセスをコードのホットパスから排除し、ローカル変数へ可能な限り初期化時に値を引き込むこと。これこそが、HHVMという猛獣を飼い慣らす唯一の道だ。
結論：コードは「機械」である
Hackは、動的なPHPの柔軟性を持ちながら、システムプログラミング言語のような制御を可能にする希有な言語である。定数畳み込みを信じるな。コンパイラが「どこで迷い、どこでガードを挿入しているか」をプロファイラ（`perf`等）で可視化せよ。
我々が書くのはスクリプトではない。CPUが実行する論理回路そのものであるという意識。それを持つ者だけが、大規模トラフィック下で1ミリ秒の遅延を削り取ることができる。
次は、HHVMの`Region-based JIT`がいかにして分岐予測をハックしているか、その深淵に触れるとしよう。