HHVMの深淵：LICMがコードの「静寂」をどう守るか
HackのランタイムであるHHVMにおいて、パフォーマンスの追求は単なる最適化ではない。それは、メモリの断片化と命令パイプラインの停滞に対する「終わりのない戦争」だ。
今日は、HHVMのJITコンパイラが最も美しく機能する領域の一つ、LICM（Loop Invariant Code Motion：ループ不変量コード移動）について深掘りしよう。教科書的な定義は諸君も知っているはずだ。「ループの反復ごとに結果が変わらない計算を、ループの外へ追い出す」というものだ。だが、HHVMの内部でそれがどう物理メモリと命令セットに翻訳されているか、その「重み」まで理解している者は少ない。
—
HHVMにおけるLICMの「現在地」
HHVMのJITエンジンは、単なるバイトコードの変換機ではない。HHVMのIR（中間表現）であるHHIRは、SSA（静的単一代入）形式を採用しており、データフロー解析が極めて強力だ。
LICMの適用において、JITコンパイラは以下の条件を厳格にチェックする。
1. 不変性の証明: その命令のオペランドがループ内で定義変更されないこと。
2. 副作用の不在: 実行しても外部状態を破壊せず、例外をスローしないこと（あるいは、ループの初回の実行前に発生することが保証されていること）。
3. 支配性（Dominance）: 移動先の場所が、元の場所を支配していること。
これらを満たすとき、HHIRはループの「Header（入口）」より前の「Pre-header」へと計算を昇格させる。
—
実践：計算を「外」へ追い出すエンジニアリング
以下のコードを見てほしい。一見、無害なHackコードだが、最適化の視点で見ると「放置すべきではない計算」が混入している。
<<__EntryPoint>>
function optimize_me(vec
// $factor 1024 はループ内で変化しない「不変量」
// しかし、記述次第でJITの推論を妨げる可能性がある
for ($i = 0; $i < $data->count(); ++$i) {
$result = $data[$i] + ($factor 1024);
echo $result . “\n”;
}
}
なぜこれが「危険」なのか
我々のようなランタイム設計者の視点で見れば、この `$factor 1024` という命令は、ループが100万回回れば100万回実行される。CPUのレジスタが空いているにもかかわらず、毎回ALUに演算を投げているのだ。
HHVMのJITは、SSA形式の最適化パスにおいて、この `($factor 1024)` を「ループの外部で評価可能」と判断する。具体的には以下の変換が行われる。
1. 解析フェーズ: `$factor` がループ内で更新されていないことを確認。
2. コード移動: ループのPre-headerに `tmp = $factor 1024` を生成。
3. 置換: ループ内の命令を `tmp` の参照に置き換え。
これにより、CPUは演算器を解放し、メモリロードあるいはレジスタ保持された値を取得するだけの「極めて軽量な命令」へと変貌する。
—
コンパイラを「黙らせる」な：最適化を阻害する境界線
シニアエンジニアが陥りやすい罠がある。それは「副作用の疑念」だ。
for ($i = 0; $i < $data->count(); ++$i) {
// ここに外部呼び出しや、推論が困難なメソッド呼び出しがある場合
// JITは「安全のために」LICMを諦める可能性がある
$result = $data[$i] + $this->calculateConstant();
}
もし `calculateConstant()` が単なるゲッターであっても、JITがその内部での副作用（例えば、グローバルな状態変更や例外の発生）を完全に排除できなければ、LICMは発動しない。
対策：極限のチューニング
1. 型ヒントの厳格化: Hackの型システムは単なるバリデーターではない。型が確定していれば、JITはガード命令を省略し、よりアグレッシブにコードを移動できる。
2. finalの活用: クラスやメソッドを `final` にすることで、デバウンス（動的ディスパッチ）を回避し、関数呼び出しをインライン化する。インライン化されれば、その内部の計算もLICMの対象になる。
—
まとめ：アーキテクトとしての視座
HHVMのJITは、君たちが書いたコードをただ実行するだけではない。君たちが「何を意図したか」というデータフローの裏側にある「真理」を読み取ろうとしている。
LICMを活用するとは、「計算の依存関係を静的に確定させること」に他ならない。ループ内で変化しないものを、ループの内部に隠すな。それをPre-headerへ引きずり出し、CPUのキャッシュラインを汚さないコードを書く。それこそが、大規模トラフィックを捌くランタイムを設計する者の矜持だ。
コードは書くものではない。マシンのリソースをどう配分するかを記述する「設計図」だということを、忘れないでほしい。
次は、HHIRのプロファイリングベースの最適化（PGO）と、それがどう実行時の分岐予測を支配するかについて語ろう。準備はいいか？