HHVMの深淵：JIT生成コードとガベージコレクションの共生メカニズム
HHVM（HipHop Virtual Machine）のアーキテクチャ、そしてその心臓部であるJIT（Just-In-Time）コンパイラとメモリ管理システムの相互作用について、表面的な解説は不要だろう。シニアエンジニアやセキュリティ研究者であるならば、マネージドランタイムがネイティブの機械語とどのように協調し、数百万リクエストを捌く裏でいかにしてメモリの整合性を保っているのか、その「実態」を知る必要がある。
本稿では、HHVMが生成するJITコードとガベージコレクション（GC）が、メモリ空間上でどのように交差し、お互いを制約し合っているのかを極限の低レイヤ視点から解き明かす。
—
1. HHVMメモリレイアウトの全体像：Native Heap vs TC Heap
一般的なプロセス空間とは異なり、HHVMは独自のメモリ領域を巧妙に配置することで、動的言語であるHackのパフォーマンスをC++ネイティブ領域に近づけている。
特に重要なのが、JITが生成した機械語を保持する TC（Translation Cache）Heap と、オブジェクトや配列を管理する GC Managed Heap の分離と共存だ。
[ Process Virtual Address Space ]
+—————————————+
| Text Segment (HHVM binary) |
+—————————————+
| TC Heap (Translation Cache / RWX/RX) | <-- JIT生成された機械語 (x86_64 / ARM64)
+---------------------------------------+
| GC Managed Heap (Objects, Arrays) | <-- 世代別 / 非同期GCの管理領域
+---------------------------------------+
| Native Heap (jemalloc / tcmalloc) | <-- C++構造体、TC内部のメタデータ
+---------------------------------------+
TC Heapの制約とセキュリティ要件
JITコンパイラは、バイトコード（HHBC）をリアルタイムにホストマシンのネイティブ命令に翻訳し、TC Heapに書き込む。
近代的なOSのセキュリティモデル（W^X: Write XOR Execute）において、メモリ領域は「書き込み可能（W）」であるか「実行可能（X）」であるかのどちらかでなければならない。HHVMはこの制約を突破するため、JITのコード生成フェーズでは書き込み許可を与え、生成完了後（あるいはコードキャッシュのロック時）に実行権限のみに切り替えるアトミックなページ保護操作（`mprotect`やプラットフォーム固有のAPI）を行っている。
—
2. JIT生成コードとGCの逢う魔時：Safe PointsとSafetap
ここで最大の課題が生じる。「JITが実行中のネイティブコードの真っただ中で、GCが走ったらどうなるか？」
GCがオブジェクトグラフを走査し、メモリをコンパクション（移動）させるとき、もしCPUレジスタやJIT生成コードのスタックフレーム内に、移動前のオブジェクトへの「生ポインタ（Raw Pointer）」が保持されていたらどうなるか。GCがそのオブジェクトを別のメモリアドレスへ移動させた瞬間、JITコード内のポインタは「ダングリングポインタ」となり、即座にセグメンテーションフォルト、あるいは致命的なメモリ破壊を引き起こす。
この矛盾を解決するため、HHVMのJITはコード生成時に以下のメカニズムを組み込んでいる。
1. Safepoint（セーフポイント）の埋め込み
JITは、オブジェクトアロケーションやメソッド呼び出しなど、GCが発動する可能性のある境界（Safepoint）を正確に把握している。
2. Stack Maps（スタックマップ）の生成
コンパイラは、各Safepointにおいて「どのCPUレジスタやスタックオフセットに、どのGC管理オブジェクトへのポインタが存在するか」を記述したメタデータ（Stack Map）を静的に構築し、TCのメタデータ領域に保持する。
コード例：GCフレンドリーなHackのデータ構造とJITの挙動
以下のHackコードを見てみよう。大量のアロケーションを伴うループ処理だ。
namespace Hack\DeepDive;
class Node {
public ?Node $next;
public function __construct(public int $value) {
$this->next = null;
}
}
function process_nodes(int $limit): int {
$head = new Node(0);
$curr = $head;
for ($i = 1; $i < $limit; ++$i) {
// ここでのインスタンス生成は、TCコードからGCアロケータへのコールを伴う
$newNode = new Node($i);
$curr->next = $newNode;
$curr = $newNode;
}
return $curr->value;
}
このコードがJITによって最適化されるとき、`new Node()` の呼び出し部分は単なる `malloc` ではなく、HHVMのスレッドローカル・アロケータ（Tlab: Thread-Local Allocation Buffer）へのインラインポインタバンプ（ポインタを必要バイト数分進めるだけの高速な操作）にコンパイルされる。
しかし、TLABが枯渇した瞬間、JITコードは処理を中断し、ランタイムのヘルパー関数（スローパス）に処理を委譲（VMレジスタの退避とセーフポイントへの移行）する。ここで初めてGCが介入する余地が生まれるのだ。
—
3. 参照カウントとジェネレーショナルGCのハイブリッド協調
HHVM（およびPHP）のメモリ管理の根底には参照カウント（Reference Counting）があるが、これだけでは循環参照のリークや、マルチスレッド環境でのアトミック操作のオーバーヘッドが大きすぎる。そのため、HHVMは高度な最適化を行っている。
1. 参照カウントのJIT側での排除（Scalar Replacement / Ref-count Elimination）
JITコンパイラは、型チェッカーによって保証された静的型情報や、スコープ解析（Escape Analysisの変種）を用いることで、「このローカル変数はメソッドの外に出ない、かつ生存期間が完全に予測できる」と判定した場合、そのオブジェクトに対する `req::ptr`（参照カウント）のインクリメント/デクリメント操作を完全に消去（Elision）する。
これにより、CPUキャッシュを汚染するアトミックなメモリバスロック命令が排除され、ネイティブ言語並みの速度が達成される。
2. ライトバリア（Write Barrier）とGCの連携
オブジェクトのプロパティ書き換え時（例: `$curr->next = $newNode;`）、もし「古いジェネレーション（世代）のオブジェクト」から「新しいジェネレーションのオブジェクト」への参照張替えが発生した場合、ジェネショナルGCのトレーシング漏れを防ぐためにライトバリアが発動する。
JITは、このライトバリアの機械語命令を直接出力する。
擬似的なx86_64 JIT出力例: $curr->next = $newNode のライトバリア
movq %rdi, 0x18(%rax) # 実際のポインタ代入 ($curr->next = $newNode)
testb $1, 0x3(%rax) # 世代フラグのチェック (Card Table Mark)
jnz .Lwrite_barrier_skip
call c_helper_write_barrier # 世代間参照リスト（Remembered Set）への登録
.Lwrite_barrier_skip:
このインライン化されたカードマーク（Card Marking）チェックにより、フルGCを走らせることなく、若い世代のヒープだけを高速に回収することが可能になる。
—
4. セキュリティと最適化の境界：JITコードのライフサイクル管理
最後に、セキュリティ研究者の視点から、TC Heapのライフサイクルと脆弱性・防御機構について言及しておこう。
JIT Heapは実行可能メモリを持つため、攻撃者にとっての標的（Code Injection / Code Reuseの踏み台）になりやすい。HHVMではこれに対し、以下の多重防御を施している。
- W^Xの厳格な維持: コード生成・パッチ適用時を除き、TCページは決して書き込み可能にならない。
- TCのフラッシュ（Invalidation / Retranslation）: プロファイリング結果（Type Feedback）が変化し、JITされたコードの型推論が無効になった場合（Deoptimization）、該当するTC領域は無効化され、再翻訳が行われる。この際、古い機械語コードは即座に上書き、あるいはパージされ、ポインタの参照先が宙ぶらりんにならないようVMのスレッド同期が厳密に行われる。
—
結びにかえて
Hackの静的型システムがもたらす恩恵は、開発時のDX（開発者体験）向上だけにとどまらない。その厳格な型境界こそが、HHVMのJITコンパイラに「高度な最適化の余地」を与え、さらにGCやメモリ管理システムとの間で無駄な動的チェックを排除した極限のランタイム効率を生み出している。
JIT生成コードとガベージコレクションのダンスは、ミリ秒単位、いやナノ秒単位の調律の結晶である。この背後にある仕組みを脳内で完全にトレースできたとき、あなたも真のHack/HHVMマエストロの領域に到達しているはずだ。