HackのEnum型とJIT：switch文の最適化がジャンプテーブルに変換される条件
動的型付け言語の遺産を引きずりながら、いかにしてネイティブコードと同等の実行速度を叩き出すか。この至上命題に対するHHVM（HipHop Virtual Machine）の回答が、高度な静的型システムとJITコンパイラの緊密な協調である。
本稿では、Hackの「`enum`（列挙型）」に焦点を当て、それが`switch`文による条件分岐と組み合わさった際、HHVMのJITコンパイラ（特にHHIRからx86-64/AArch64アセンブリへのトランスレートフェーズ）において、いかにして極限まで最適化されたジャンプテーブル（間接分岐）へと変貌を遂げるのか、その内部メカニズムを解剖する。
—
1. 静的型システムとJITの血流：なぜHackのEnumは高速なのか
PHPにおける広義の「列挙型」や連想配列による代替は、ランタイムにおいて常に文字列やハッシュマップのルックアップというオーバーヘッドを伴う。これに対し、Hackの`enum`はゼロコスト抽象化（Zero-Cost Abstraction）を基本思想としている。
enum TrafficLight: int {
RED = 0;
YELLOW = 1;
GREEN = 2;
}
静的解析フェーズ（`hh_client`）において、`TrafficLight`は厳格な型安全性を強制されるが、HHVMのランタイムにおいては、単なるプレーンな`int`（`TypedValue`における`m_type = KindOfInt64`）として扱われる。この「静的な厳格性と動的な単純性」の二面性こそが、JITコンパイラが極めて効率的なマシン語を出力するための大前提となる。
HHVMのJITコンパイルは、以下の多段階のIR（中間表現）を経て行われる。
1. HHBC (HHVM Bytecode): バイトコードレベル。`Switch`や`SSwitch`（文字列用）命令。
2. HHIR (HHVM Intermediate Representation): 強く型付けされたSSA形式のIR。ここで型ガードの最適化や冗長コードの削除が行われる。
3. VASASM (Virtual Assembler ASM): レジスタ割り当て前のアーキテクチャ抽象化アセンブラ。
4. Native Code (x86-64 / AArch64): 最終的なマシン語。
`enum`が`int`に裏打ちされている場合、HHIRは「値の範囲が限定された整数」としてこれを最適化パイプラインに流し込むことができる。
—
2. HHIRにおける分岐最適化アルゴリズム：密（Dense）と疎（Sparse）の境界線
JITコンパイラが`switch`文に遭遇した際、生成するコードの戦略は主に3つ存在する。
1. 線形探索（Linear Search / Cascading Compare）: `if-else`の連続。ケース数が極めて少ない場合（通常3〜4以下）に採用される。
2. 二分探索（Binary Search Tree）: ケース数が中規模で、かつ値が非連続（疎）な場合に採用される。$O(\log N)$の比較・分岐。
3. ジャンプテーブル（Jump Table / Indirect Branch）: ケース数が多く、かつ値が連続（密）している場合に採用される。境界チェックの後は$O(1)$で目的のアドレスへジャンプする。
HHVM JITが「ジャンプテーブル」を選択する境界条件は、HHVMソースコード内の`hhvm/runtime/vm/jit/normalized-instruction.cpp`および各アーキテクチャのコードジェネレータ（`cg-x64.cpp`など）に定義されている。
ジャンプテーブル採用の判定基準
JITがジャンプテーブルを採用するためには、以下の数式を満たす必要がある。
$$\text{Density} = \frac{\text{ケース数}}{\text{最大値} – \text{最小値} + 1} \ge \text{Threshold (通常 0.5)}$$
かつ、最小ケース数（通常 4以上）を満たしている必要がある。
例えば、以下の2つのEnumを考える。
// パターンA: 密なEnum（Dense）
enum DenseEnum: int {
A = 10;
B = 11;
C = 12;
D = 13;
E = 14;
}
// パターンB: 疎なEnum（Sparse）
enum SparseEnum: int {
A = 10;
B = 100;
C = 1000;
D = 10000;
}
- パターンA: $\text{Density} = 5 / (14 – 10 + 1) = 1.0$。閾値をクリアし、ジャンプテーブルが生成される。
- パターンB: $\text{Density} = 4 / (10000 – 10 + 1) \approx 0.0004$。閾値を大きく下回るため、JITは二分探索ツリーによる条件分岐を生成する。
—
3. 実証コード：Hack Enumによる条件分岐
最適化の挙動を追跡するため、以下の検証用コードを用意する。
<<__EntryPoint>>
function main(): void {
// PGO（プロファイル駆動最適化）をシミュレートするため、ループ内で実行
for ($i = 0; $i < 1000_000; $i++) {
$val = DenseEnum::assert($i % 5 + 10); // 10〜14の値を生成
consume_dense($val);
}
}
enum DenseEnum: int {
CASE_A = 10;
CASE_B = 11;
CASE_C = 12;
CASE_D = 13;
CASE_E = 14;
}
<<__NEVER_INLINE>>
function consume_dense(DenseEnum $val): void {
switch ($val) {
case DenseEnum::CASE_A:
text_out(“A”);
break;
case DenseEnum::CASE_B:
text_out(“B”);
break;
case DenseEnum::CASE_C:
text_out(“C”);
break;
case DenseEnum::CASE_D:
text_out(“D”);
break;
case DenseEnum::CASE_E:
text_out(“E”);
break;
}
}
function text_out(string $_s): void {
// JIT最適化でデッドコード削除されないためのダミー処理
asm_noop();
}
function asm_noop(): void {}
—
4. アセンブラレベルの深淵：JIT出力コードの解読
上記コードがHHVMのJIT（x86-64ターゲット）によってネイティブコンパイルされた際のアセンブリコードをトレースする。
JITはまず、`consume_dense`関数に入力された引数 `$val`（レジスタ `rdi` に格納されていると仮定）が、JITコンパイル時に前提とした型（`Int64`）に適合しているかの型ガード（Type Guard）を行う。その後、ジャンプテーブルを用いた以下のコードブロックを展開する。
生成されるx86-64アセンブリ（概念的再現）
; — 引数の取得とローカルレジスタへの展開 —
; rdi: 第1引数 ($val) が格納されている
; — 1. 最小値（10）を引いてインデックス化する (Offset Normalization) —
sub rdi, 10 ; rdi = $val – 10
; — 2. 境界チェック (Bounds Check) —
; インデックスが 0 未満、または 4 (最大インデックス) 超過の場合は default ケース（今回は存在しないが安全のため）またはSide Exitへ
cmp rdi, 4
ja .L_DEFAULT_OR_MISS ; 符号なし比較(ja)により、負数（アンダーフローで巨大な数になる）と4超を一括検知
; — 3. ジャンプテーブルを使用した間接分岐 —
; rip相対で配置されたジャンプテーブルのアドレスをロードし、スケールド・インデックス（8バイト幅）でジャンプ先を取得
lea rsi, [rip + .L_JUMP_TABLE] ; rsi = ジャンプテーブルのベースアドレス
movsxd rax, dword ptr [rsi + rdi4] ; 32ビット相対オフセットをサイン拡張してロード（バイナリサイズ削減テクニック）
add rax, rsi ; 絶対アドレスに変換
jmp rax ; 間接ジャンプ (Indirect Branch)
; — データの整合性を保つためのアライメント —
.align 4
.L_JUMP_TABLE:
.long .L_CASE_A – .L_JUMP_TABLE ; CASE_A (10) へのオフセット
.long .L_CASE_B – .L_JUMP_TABLE ; CASE_B (11) へのオフセット
.long .L_CASE_C – .L_JUMP_TABLE ; CASE_C (12) へのオフセット
.long .L_CASE_D – .L_JUMP_TABLE ; CASE_D (13) へのオフセット
.long .L_CASE_E – .L_JUMP_TABLE ; CASE_E (14) へのオフセット
; — 各ケースの処理本体 —
.L_CASE_A:
; text_out(“A”) の呼び出し処理
…
jmp .L_EPILOGUE
.L_CASE_B:
…
jmp .L_EPILOGUE
…
アーキテクチャ解説：なぜこのコードは高速なのか？
1. `sub rdi, 10` による正規化:
Enumの値が `10` から始まっているため、そのままテーブルインデックスに使用すると先頭に10個の空き要素（無駄なメモリ）が生じる。JITはバイアス（最小値）をコンパイル時に計算し、実行時には単一の減算命令でインデックスを `0` 起点に正規化する。
2. `ja`（Jump if Above）によるワンショット・バウンズチェック:
符号なし比較を行うことで、負の値（`$val < 10` の結果、`rdi`が巨大な値になる）と、最大値超過（`$val > 14`）を1回の比較命令と1回の条件分岐命令で同時に処理している。これはコンパイラ最適化の定石である。
3. 相対オフセットテーブルと間接ジャンプ:
64ビットの絶対アドレスを直接テーブルに持つのではなく、32ビットの相対オフセット（`.long`）を持つことで、L1キャッシュのライン（64バイト）に格納できるテーブル密度を倍増させている。キャッシュミスはJITコード実行時における最大の敵であり、このサイズ削減はスループットに直撃する。
—
5. PGO（Profile-Guided Optimization）と分岐予測の動的相転移
HHVMの真の強みは、実行時のプロファイリング情報をフィードバックするPGO（プロファイル駆動最適化）にある。
Enumの`switch`分岐がジャンプテーブル化される条件を満たしていても、PGOの統計データが「特定のケースが99%を占める」と報告した場合、JITはジャンプテーブルを生成しない。
バイアスが極端な場合のPGO出力コード構造
もし統計上、`CASE_A`が圧倒的に「Hot」である場合、JITは以下のようなコードを生成する。
cmp rdi, 10 ; $val == CASE_A?
je .L_CASE_A_HOT ; 予測が当たれば、間接ジャンプを避けてダイレクトジャンプ！
; — 予測が外れた場合のフォールバック（Cold Path） —
; ここで初めてジャンプテーブル、または二分探索を実行する
…
間接分岐（`jmp rax`）は、CPUの分岐予測ユニット（Branch Target Predictor / BTB）に大きな負荷をかける。特に近代的なCPU（Intel Golden CoveやAMD Zen 4など）は優れた間接分岐予測機構を持つが、直接分岐（`je`）に比べれば予測ミスのペナルティリスクは依然として高い。
PGOは、ジャンプテーブルという「フラットな最適化」をあえて崩し、最も発生頻度の高いパスを「直列の高速道路」として切り出す。この動的な最適化制御こそが、HHVMが大規模マルチスレッド環境下で高いIPC（Instruction Per Cycle）を維持できる秘密である。
—
6. JITが最適化を「諦める」限界点：アンチパターンとその対策
静的型システムをバイパスするようなコード、あるいはEnumの不適切な設計は、JITによるジャンプテーブル生成を阻害し、実行速度を急転直下させる。
アンチパターン1：疎すぎるEnum値（Sparse Enum）
enum BadEnum: int {
INIT = 0;
PROCESSING = 100;
COMPLETED = 10000;
}
この場合、前述のDensity計算式によりジャンプテーブルは生成されず、二分探索木の比較コード（`cmp` と `jl/jg` の連続）が生成される。
対策: Enumの整数値は、可能な限り `0` から始まる連続値（Dense）として設計せよ。内部的なID管理などで非連続な値が必要な場合は、システム境界で連続値のEnumへマッピングし直すレイヤーを挟むのが賢明である。
アンチパターン2：`enum class`における非プリミティブな多態性
Hack 4.xで導入された `enum class` は強力な機能だが、具象インスタンスをラップした複雑なオブジェクトを対象にする場合、JITは型ガードの解決に追われ、単純なレジスタオフセットによるジャンプテーブルを構成できなくなる。
// enum class の例
enum class MyEnumClass: IProcessor {
ProcessorA = new ConcreteProcessorA();
ProcessorB = new ConcreteProcessorB();
}
このようなケースでは、JITはオブジェクトのクラスヘッダを確認し、仮想関数テーブル（vtable）を経由した動的ディスパッチを生成せざるを得ない。これはハードウェアレイヤーにおいては「重い」処理である。
対策: 高頻度で呼び出されるホットパスの分岐においては、複雑な `enum class` のポリモーフィズムよりも、整数値ベースのクラシックな `enum` と `switch` の組み合わせを選択すべきである。
—
7. 結論：ハードウェアを支配するための設計論
HHVM JITにとって、Hackの静的型システムは「静的解析ツールを喜ばせるための飾り」ではない。それは、JITコンパイラが余計な型安全ガードを徹底的に削ぎ落とし、ハードウェアのネイティブ命令（境界チェック付き間接ジャンプ）をダイレクトに叩き出すための「設計図」である。
- 連続した整数値でEnumを定義する
- 型チェッカーの警告を無視せず、`switch`の網羅性を担保する
- PGOを有効化し、ランタイムに実行時プロファイルを収集させる
この3原則を遵守する限り、あなたの書いたHackコードは、HHVMの手によって限界まで無駄を削ぎ落とされた、美しく冷徹なアセンブリコードへと昇華される。システムアーキテクトたる者、常にこの低レイヤの挙動を脳内に描画しながら、コードを設計されたし。