JITの迷宮を暴く：動的生成されたHackコードをGDBで追跡する極限の低レイヤ知見
HHVM（HipHop Virtual Machine）の心臓部であるJIT（Just-In-Time）コンパイラは、Hackの厳格な静的型システムから導き出された型情報を武器に、驚異的なスループットをもたらすマシン語を動的に生成する。
だが、極限まで最適化されたネイティブコードの海でセグメンテーション違反（SIGSEGV）や予期せぬ挙動に直面した時、標準的なデバッガの視界は閉ざされる。シンボルテーブルは消え去り、スタックトレースは生のレジスタと命令オフセットの迷宮と化すからだ。
本稿では、HHVMのJIT構造の内部に入り込み、生成されたマシン語をGDBによって如何にして追跡し、ボトルネックやクラッシュの根源を特定するか——その極限のデバッグ手法をコードの裏側のメカニズムと共に解き明かす。
—
1. HHVM JITアーキテクチャとコード生成のライフサイクル
HHVMは、Hackのバイトコード（HBC）を起動時あるいはプロファイル情報（PGO: Profile-Guided Optimization）に基づいて、x86-64のマシン語へとトランスレートする。このプロセスを司るのが Translation Cache (TC) だ。
TC領域は、OSのメモリ管理機構（`mmap`）を通じて動的に確保され、書き込み・実行権限（`PROT_READ | PROT_WRITE | PROT_EXEC`）が動的に制御される。
[Hack Source] -> (HHVM Parser/Typechecker) -> [Bytecode (HBC)]
│
▼
[HHVM JIT Engine]
│ (Translates based on PGO)
▼
[Translation Cache (TC)]
(Dynamically generated x86-64)
通常のデバッガ（GDB）は、静的なELFバイナリのシンボルを前提としている。しかし、TC内で動的に生成・実行されるコードには標準のシンボルが存在しない。そのため、JITされたコードの領域をGDBに認識させ、逆アセンブルするためのアプローチが必要となる。
—
2. デバッグ環境の構築とHHVM内部シンボルのマッピング
JITコードを追跡するためには、まずHHVMがJITのメモリ領域と関数名・バイトコードオフセットをGDBに通知するメカニズム（GDB JIT Compilation Interface）を有効化する必要がある。
必須の起動フラグ
HHVMを起動する際、JITのデバッグ支援機能を有効化する：
hhvm \
-v JitEnableNativeRelocation=true \
-v JitKeepDbgInfo=true \
-v Eval.JitLLDBgdbSupport=true \
server.php
これにより、HHVMはJITコードが生成されるたびに、GDBが解釈できるELFイメージを動的にメモリ上に構築し、GDBへ通知する。
—
3. 実践：GDBを用いたJITコードの追跡と逆アセンブル
問題のHackコードがTC内でどのように実行されているかを特定し、GDBでアセンブリレベルの解析を行う手順を示す。
ターゲットとなるHackコードの例
以下のコードで、極端なループや型変換がどのようにJITされるかを想定する。
// test_jit.hack
namespace DebugJit;
class Calculator {
public static function compute(int $n): int {
$acc = 0;
for ($i = 0; $i < $n; $i++) {
$acc += $i 2;
}
return $acc;
}
}
<<__EntryPoint>>
function main(): void {
// JITのプロファイルをウォームアップさせるためのループ
for ($j = 0; $j < 10000; $j++) {
Calculator::compute(100);
}
// ブレークポイントを仕掛けたい実際の処理
echo Calculator::compute(500) . "\n";
}
GDBのアタッチとJIT関数の特定
クラッシュ時、あるいは任意のJIT関数名でブレークしたい場合、GDBをアタッチする。
gdb -p $(pgrep hhvm)
GDB内で、HHVMが生成したJIT関数のシンボルを検索する。HHVMはJITされた関数に内部名（例：`is_`で始まるプレフィックスやクラス名）を付与している。
(gdb) info functions Calculator::compute
もしシンボルが直接引けない場合は、TC（Translation Cache）のベースアドレスを手動で特定する。HHVMの内部コマンドやログ出力（`-v Eval.DumpJit=`）からTCのアドレスレンジを取得し、その範囲を指定して逆アセンブルを行う。
TCの領域が 0x7f8a00000000 から 0x7f8a10000000 だと仮定
(gdb) disassemble 0x7f8a00100000, 0x7f8a00100100
出力例（x86-64ネイティブコード）：
Dump of assembler range 0x7f8a00100000 to 0x7f8a00100100:
0x7f8a00100000: push %rbp
0x7f8a00100001: mov %rsp,%rbp
0x7f8a00100004: xor %eax,%eax # $acc = 0 の初期化
0x7f8a00100006: xor %ecx,%ecx # $i = 0 の初期化
0x7f8a00100008: cmp %rsi,%rcx
0x7f8a0010000b: jge 0x7f8a00100020 # ループ終端判定
0x7f8a0010000d: lea (%rcx,%rcx,1),%rdx # $i 2 の最適化 (lea命令による高速算術)
0x7f8a00100011: add %rdx,%rax
0x7f8a00100014: inc %rcx
0x7f8a00100016: jmp 0x7f8a00100008
0x7f8a00100018: pop %rbp
0x7f8a00100019: ret
ここで注目すべきは、`$i 2` という演算が、静的型システム（intであることが確定している）の恩恵を受け、無駄なボックス化（Boxing/Unboxing）を完全に排除し、単一の `lea` 命令とレジスタ演算へとコンパイルされている点だ。
—
4. 低レイヤーでのボトルネック・異常検知テクニック
A. 型ガード（Type Guard）の失敗によるースの特定（Side Exit）
Hackの静的型は強力だが、動的な呼び出しや予期せぬ型混入がおきると、JITされたコードは Side Exit（ネイティブ実行からスローパスであるインタープリタや再コンパイルへの脱出）を引き起こす。これが頻発すると性能が劇的に低下する。
GDBでSide Exitの発生地点を特定するには、HHVMのスタックフレーム構造（`ActRec`）を覗く必要がある。
現在のフレームポインタからActRecの情報を確認
(gdb) p (ActRec)($rbp)
`ActRec`（Activation Record）には、現在実行中のHack関数のメソッドIDや、引数の型情報（`Cell`構造体）が格納されている。GDBのカスタムコマンドやPythonスクリプトを組み込むことで、JIT空間でのレジスタ状態とHackの変数マッピングを完全に同期させることができる。
B. メモリリーク・TC枯渇の追跡
長期間稼働するサーバープロセスにおいて、TC領域が枯渇するとHHVMはコードの再翻訳（Re-translation）ループや領域破棄を引き起こす。
GDBを用いてTCの使用率やアロケーション状況を観測するには、HHVMのグローバル管理構造体である `CodeCache` の状態をダンプする。
(gdb) p TransContext::s_code_cache
これにより、現在のTCのフラグメンテーション状態や、どの程度のエントリが生成されているかをミリ秒単位で追跡可能となる。
—
5. チーフアーキテクトからの提言
Hackの静的型システムは、単にIDEでの補完や静的解析のためのものではない。それは、HHVMのJITコンパイラに対して「安全に最適化を施すための絶対的な契約（Contract）」である。
もしあなたがパフォーマンスの限界領域に挑み、JITが生成したコードの挙動を疑う必要に迫られたならば、恐れずにGDBを手に取り、Translation Cacheのバイナリの海へ潜るがいい。レジスタの微差、`lea`命令の効率、そして型ガードの分岐の向こう側に、あなたのコードの真のパフォーマンスと、システムのすべての真理が露わになるはずだ。