HHVMのコードキャッシュ無効化戦略：デプロイ時のウォームアップを高速化するRepo Authoritativeモードの極意
大規模なHack/HHVMシステムにおいて、デプロイメントは単なるコードの置換ではない。それは、膨大なCPUサイクルを消費して構築されたJITコンパイル済みのマシンコード（Translation Cache）をいかにして破壊せず、あるいは最小限のペナルティで再構築するかという、ランタイム工学の極限の挑戦である。
数百万行を超えるモノリス構造のHackアプリケーションにおいて、ナイーブなプロセス再起動は、デプロイ直後のJITキャッシュ喪失によるCPUスパイク（Cold Start問題）を引き起こし、一時的なサービス不能状態（スループットの急落とレイテンシのスパイク）を招く。
本稿では、HHVMの実行モードの頂点であるRepo Authoritative (RepoAuth) モードを前提とし、JITコードキャッシュの内部アーキテクチャ、メモリマップの構成、そしてデプロイ時のウォームアップコストを極限まで削減するためのシステムアーキテクチャ設計について、HHVMコアコミッターの視点から解説する。
—
1. Repo Authoritativeモードの深層：Closed-World Assumptionがもたらす型最適化
HHVMをプロダクションで動作させる際、パフォーマンスを最大化するための絶対条件が `Repo Authoritative` モード（以下、RepoAuthモード）である。
通常のインタープリタや動的JIT環境とは異なり、RepoAuthモードは「実行時にはコードベースが一切変更されない」というクローズド・ワールド仮定（Closed-World Assumption）をランタイムに強制する。
[ビルドフェーズ]
Hackソースコード (.hack)
│
▼ (hh_single_compile)
抽象構文木 (AST) & 静的型解析
│
▼
独自のバイトコード (HHBC) へコンパイル
│
▼
SQLite データベース (hhvm.hhbc) として1つのバイナリにパッケージ化
───────────────────────────────────────────────────────
[ランタイムフェーズ]
HHVM 起動
│ (hhvm.hhbc を排他的にロード)
▼
実行時にはディスク上のソースコードを一切見ない
なぜRepoAuthモードがJITを高速化するのか？
このクローズド・ワールド仮定により、HHVMのJITコンパイラ（`jit::Translator`）は、通常の動的言語ランタイムでは不可能なレベルの静的最適化を施すことができる。
1. 完全な脱仮想化（Devirtualization）
あるインターフェース `I` を実装するクラスが、コンパイル時点でクラス `A` のみであると決定できる場合、インターフェースを介したメソッド呼び出しを、間接ジャンプ（Indirect Jump）から直接呼び出し（Direct Call）、あるいはインライン展開（Inlining）へと静的に変換する。
2. 定数およびグローバル関数の畳み込み
すべての定数定義やグローバル関数がビルド時に確定しているため、実行時のルックアップテーブルの参照を排除し、即値（Immediate）としてコンパイルコードに埋め込む。
3. 高精度な型推論の固定化
HHVMは静的型チェッカー（`hh_client`）の解析結果と、HHBCコンパイラが生成する型アノテーションを信頼し、実行時の型チェック（Type Guard）を大幅に省略したマシンコードを生成する。
—
2. JITキャッシュ（Translation Cache）のメモリマップと再構築のメカニズム
JITコンパイラが生成したx86_64/ARM64のマシンコードは、Translation Cache (TC) と呼ばれるメモリ領域に格納される。このTCは単一のフラットなメモリ領域ではなく、コードの実行頻度と特性に応じて複数の「Arena」に分割管理されている。
TCのアリーナ構造
| アリーナ名 | 主な格納対象 | 特徴 |
| :— | :— | :— |
| `unique` | ヘルパー関数、ランタイムの共通エントリポイント | プロセス生存期間中、再生成されることがほぼない不変のコード。 |
| `primary` (hot) | 頻繁に実行されるメインパス（JIT最適化コード） | 高い分岐予測ヒット率を維持するため、連続したメモリ空間に配置される。 |
| `cold` | 例外ハンドリング、型ガード失敗時のフォールバックパス | メインのインストラクションキャッシュ（L1I）を汚染しないよう、物理的に離れた場所に配置される。 |
| `frozen` | 致命的なエラーハンドリング、アサート失敗パス | ほぼ実行されないコード。メモリの局所性を保つために完全に隔離される。 |
デプロイ時におけるTCのジレンマ
RepoAuthモードにおいて、新しいバージョンのアプリケーションをデプロイするということは、新しい `hhvm.hhbc` をロードした新しいHHVMプロセスを立ち上げることを意味する。
JITコンパイルされたコード（TC）は物理メモリ上の絶対アドレスや、プロセス固有の内部データ構造（関数ポインタ、クラスメタデータのアドレス）に依存しているため、プロセス間でTCを直接共有・コピーすることは原理的に不可能である。
したがって、新プロセスは「完全に冷え切った（Cold）」TCを持って起動せざるを得ず、起動直後のリクエストはインタープリタ実行、あるいはその場でのJITコンパイル（Just-In-Time Compilation）を強制される。これが、デプロイ直後にCPU使用率が100%に張り付き、リクエストがタイムアウトする原因である。
—
3. 極限のウォームアップ戦略：PGOとPre-translationの統合
このCold Start問題を克服するために、HHVMはPGO (Profile-Guided Optimization) および Pre-translation（事前JITコンパイル） の機構を提供している。これらを組み合わせることで、トラフィックを投入する前にTCの主要部分（ホットパス）を「温める」ことができる。
構成アーキテクチャ
[本番環境のコンテナ A] (稼働中)
│
├─► リアルタイムの実行プロファイル (PGOデータ) を定期エクスポート
│
[ビルドパイプライン]
├─► PGOデータを回収
├─► 新しいソースコードと統合
├─► `hh_client` による静的検証
├─► `hhc` によるバイトコード生成（hhvm.hhbc）
│ ※この時点で「どの関数がホットか」のメタデータを埋め込む
▼
[新コンテナ B] (デプロイ起動)
│
├─► 起動時に `hhvm.hhbc` をロード
├─► バックグラウンドスレッドが起動し、ホットな関数を事前JIT化（Pre-translate）
├─► ローカルウォームアップ・リクエストの自動実行
▼
[ロードバランサ] ──► ヘルスチェック通過後、トラフィックをBへ切り替え
PGOとJITウォームアップを有効化する極限の `php.ini` 設定
以下は、プロダクション環境において、デプロイ時のJITウォームアップを最大化するためのHHVMシステム構成設定である。
hhvm.ini – プロダクション極限設定
Repo Authoritative モードの強制
hhvm.repo.authoritative = true
hhvm.repo.path = /var/var/hhvm/hhvm.hhbc
JITの基本有効化とメモリ確保
hhvm.jit = true
hhvm.jit_warmup_requests = 100
TC（Translation Cache）のサイズ設定（大規模システム向けに大きく確保）
hhvm.jit_a_size = 104857600 # primary (100MB)
hhvm.jit_a_cold_size = 41943040 # cold (40MB)
hhvm.jit_a_frozen_size = 41943040 # frozen (40MB)
Profile-Guided Optimization (PGO) の有効化
hhvm.jit_pgo = true
hhvm.jit_pgo_hot_only = true
hhvm.jit_pgo_use_data_serializer = true
hhvm.jit_pgo_schema_path = /var/var/hhvm/hhvm.pgo.schema
起動時のPre-translation（事前コンパイル）スレッド数
CPUコア数に合わせて最適化し、起動フェーズのバックグラウンドコンパイルを加速
hhvm.num_jit_worker_threads = 8
プロセス起動時に強制的に内部リクエストを走らせてウォームアップする設定
指定したパスのスクリプトを、外部トラフィックを受け入れる前に実行する
hhvm.warmup_requests[] = /var/var/hhvm/warmup_entry.php
—
4. 実証：AOT最適化を極限まで引き出すHackコードの設計
JITコンパイラが起動時およびランタイム実行時に最適化を最速で完了させるためには、コード側でもコンパイラに優しい（JIT-friendly）構造設計を行う必要がある。
以下に、コンパイラが型推論を100%確定でき、型ガード（Type Guard）を一切生成せずに直接マシンコードへとコンパイル可能にするHackコードの極限例を示す。
/
namespace HHVM\Opt\Demo;
// finalクラスにすることで、JITコンパイラはこのクラスが継承されないことを確信できる（脱仮想化の成立）
final class ExecutionContext {
// すべてのプロパティに厳格な型アノテーションを付与
// ヌル許容型(?stringなど)を可能な限り排除することで、メモリレイアウトがフラットになり、
// JITはヌルチェックの条件分岐を省略できる
private string $requestId;
private int $timestamp;
private dict
public function __construct(
string $requestId,
int $timestamp,
dict
) {
$this->requestId = $requestId;
$this->timestamp = $timestamp;
$this->metadata = $metadata;
}
// finalメソッド、かつ厳格な型シグネチャ
public final function getFormattedLog(string $message): string {
// 局所変数もすべて型が自明
// 文字列連結は、JIT内部で専用のヘルパー（jit::vconcat）に直接コンパイルされる
return “ID:”.$this->requestId.” | Time:”.(string)$this->timestamp.” | Msg: “.$message;
}
public final function getMeta(string $key): ?string {
// dictの参照は、ランタイムのC++高速パス（ArrayData::nvGet）へ直接マップされる
return idx($this->metadata, $key);
}
}
/
- ウォームアップ時に実行されるエントリポイント
/
<<__EntryPoint>>
async function run_warmup(): Awaitable
// 擬似的なコンテキストを生成してループ実行
// ループ回数は、JITが「ホットパス」と認識する閾値を超えるように設計する
$meta = dict[‘env’ => ‘production’, ‘tier’ => ‘api’];
// 1000回以上のイテレーションにより、JITのプロファイリングフェーズから
// 最適化JIT（Optimizeラン）への遷移を強制的にトリガーする
for ($i = 0; $i < 1500; $i++) {
$context = new ExecutionContext(
"req_".(string)$i,
\time(),
$meta,
);
$log = $context->getFormattedLog(“Warmup event iteration.”);
$env = $context->getMeta(“env”);
// 生成物のアサート（デッドコード排除によるループ全体の最適化消滅を防ぐ）
if ($env === null || \strlen($log) === 0) {
throw new \Exception(“Optimization failed: dead code elimination safety hazard.”);
}
}
// システム標準出力へのログ出力
\file_put_contents(‘php://stdout’, “Warmup sequence completed successfully.\n”);
}
コンパイラ・ランタイムレベルでの解説
- `final class` と `final function`:
これらにより、JITコンパイラは `vtable`（仮想関数テーブル）を介した呼び出しを完全に排除する。`getFormattedLog` への呼び出しは、アセンブリレベルで単なる `call` 命令（またはインライン展開による命令列の埋め込み）に変換される。
- デッドコード排除（Dead Code Elimination: DCE）の回避:
JITコンパイラは非常に強力であるため、戻り値がどこにも使われていないループを検知すると、ループ自体を消滅（DCE）させてしまう。ウォームアップの意味をなさなくなるため、`if ($env === null || \strlen($log) === 0)` のような形で、副作用を保証するコードを挟み込んでいる。
—
5. 無停止デプロイメント（Graceful Socket Transition）の極意
事前ウォームアップが完了した新プロセスに対し、リクエストを切り替える瞬間にも、ミリ秒単位のパケットロスすら防ぐためのインフラストラクチャレベルの協調が必要となる。
HHVMは、同一ポートのリスニングソケットを新旧プロセス間で安全に引き渡すための仕組み、あるいはロードバランサとの連携機能を備えている。
ゼロダウンタイム・ソケットテイクオーバーの流れ
[クライアント]
│
▼ (ポート 80/443)
[Nginx / Proxygen (リバースプロキシ)]
│
├─► [旧 HHVM プロセス (PID: 1001)] (アクティブ)
│ ※ USR2シグナルを受信
│ ※ 新規接続の受付を停止、既存リクエストの処理（Graceful Shutdown）に移行
│
├─► [新 HHVM プロセス (PID: 2002)] (ウォームアップ完了済み)
※ 共有ソケット、またはSO_REUSEPORTを利用して同一ポートでの受付を開始
※ 即座に最適化JITコードでリクエストを処理
運用における実践的デプロイメントステップ
1. バックグラウンドビルド:
ビルドサーバー上で最新のソースコードをターゲットに `hh_client` を走らせ、`hh_single_compile` を使って `hhvm.hhbc` を生成。
2. プレ・プレパレーション:
ターゲットサーバーの別ディレクトリ（例: `/var/deploy/releases/v2/`）に `hhvm.hhbc` およびPGOデータを配置。
3. ウォームアップ専用プロセス起動:
メインポートとは異なる「管理用ポート（Admin Port）」、あるいはローカルソケットを指定して新HHVMを起動。
この際、`warmup_requests` に指定されたコードが走り、主要なHHBCがJITの `primary` アリーナにマシンコードとしてコンパイルされる。
4. シグナルハンドリングによる切り替え:
新プロセスがポートを引き継ぐ（`SO_REUSEPORT` を活用）、もしくはプロキシ（Nginx/HAProxy）の上流定義（Upstream）を書き換えて、一瞬で新プロセスへとトラフィックをスワップする。
5. 旧プロセスのドレイン（Drain）:
旧プロセスに `SIGUSR2` を送信。これにより、旧プロセスは新規リクエストの受付を止め、現在処理中のリクエスト（In-flight Requests）がゼロになった時点で自律的にシャットダウンする。
—
まとめ：静的型システムと仮想マシンの完全なる調和
HHVMのJITコンパイル効率を極限まで高め、デプロイ時のパフォーマンス劣化を完全に防ぐためには、「コンパイラにコードベースのすべてを把握させる（Closed-World）」こと、そして「動的な変更を一切許容しない厳格な型設計を徹底する」ことに尽きる。
ランタイムの挙動、メモリマップ、そしてコンパイラの特性を深く理解し、インフラとコードの両面からアプローチすることで、数百万リクエストを裁く超巨大エンタープライズ環境であっても、瞬時のデプロイと超高速な初期応答速度を両立させることが可能となるのだ。