PHPコアの深淵：循環参照とJITコード生存期間のメタデータリークメカニズム
PHPは単なる「手軽なWebスクリプト言語」ではない。Zend VMという高度な仮想マシン、OPcacheという共有メモリ（SHM）上の高速実行基盤、そしてPHP 8で導入されたJIT（Just-In-Time）コンパイラが織りなす、極めて洗練されたランタイムである。
本稿では、フレームワークの内部や複雑なドメインモデル設計において避けて通れない「循環参照（Circular Reference）」と「JITコンパイルされたネイティブコードの生存期間（Lifecycle）」という、一見無関係に見える2つの要素が、如何にしてZendエンジン内部で交錯し、メモリリークや予期せぬパフォーマンス劣化を引き起こすのかを、低レイヤのメモリ管理モデルから徹底的に解剖する。
—
1. Zend VMにおけるメモリ管理の基礎：RCとGCの限界
PHPのメモリ管理は、基本的には `zend_value` が持つ参照カウンター（Reference Counter: `refcount`）によって駆動されている。変数がスコープを抜ける、あるいは `unset()` されると `refcount` がデクリメントされ、0になった瞬間に `efree()` が走る。これが基本のシームレスなメモリ解放メカニズムだ。
しかし、オブジェクトや配列が互いを参照し合う循環参照が発生した場合、コンテナ自体の `refcount` は0になり得ない。
例えば、以下のような構造を考えてほしい。
class Node {
public ?Node $parent = null;
public array $children = [];
}
$parent = new Node();
$child = new Node();
$parent->children[] = $child;
$child->parent = $parent; // 循環参照の成立
unset($parent, $child);
このコードを実行すると、`$parent` と `$child` の変数はスコープから消去されるが、お互いを指し示すポインタが残っているため、それぞれの `refcount` は `1` のまま残存する。これがゾンビのようにヒープ領域を食潰す、通常のPHPメモリリークの正体だ。
これに対処するため、PHPは Concurrent Cycle Collection Algorithm（並行サイクル回収アルゴリズム） を `zend_gc.c` に実装している。
バッファ（`gc_globals.buf`）の容量がしきい値（デフォルトでは10,000ルート）に達すると、GCは以下の4ステップで回収を行う：
1. 色彩づけ（Coloring roots）: 疑わしいバッファ内の黒いノードを灰色にマークし、`refcount`を仮想的に減算する。
2. スキャン（Scanning colors）: 実際に循環しているかを判定するため、到達可能性を走査する。
3. 白化（Whitening）: 到達不能（外部から参照されていない孤立した循環構造）であると判定されたものを白（回収対象）にマークする。
4. 解放（Freeing）: 白いノードをメモリプールへ返却する。
このGCメカニズム自体は非常に堅牢だが、問題はこれが「JITコンパイラが生成するネイティブコードのメタデータ（JIT Trace / Persistent Region）」とどのように相互作用するかという点にある。
—
2. JITコード生成とメタデータ構造体
PHP 8のJIT（DASM / DynASMベース）は、OPcacheの共有メモリ（SHM）内にネイティブの機械語命令を直接マッピングする。
通常のバイトコード（`zend_op_array`）はプロセスごとに存在し得るが、JITによって生成されたマシンコードは、`opcache.jit_buffer_size` で確保された巨大な連続した実行可能メモリ領域に配置される。
JITコンパイラが有効な場合、Zend VMはホットスポット（高頻度で実行されるループや関数）を検出し、プロファイル情報（Execution Counters）をもとにネイティブコードへとトランスレートする。ここで生成されるのは単なるバイナリだけでなく、以下のメタデータがセットで管理される：
- JIT Trace Index: どのOPコード列がどのマシンコードアドレスにマップされているかのインデックス。
- Polyline / Guard Records: 型の変動やクラスの変更を監視するためのガード条件（例：「このオブジェクトのクラスは実行時も変更されていないか？」というインラインキャッシュのメタデータ）。
これらのメタデータは、プロセス固有のヒープ（EMALLOC / zend_mm_heap）、あるいはOPcacheの共有メモリ上に複雑なポインタネットワークとして構築される。
—
3. 循環参照がJITの生存期間（Lifespan）とメモリ空間に与える致命的影響
ここに、極めて厄介なアーキテクチャ上のジレンマが存在する。
① インラインキャッシュ（Inline Cache）とオブジェクトの永続化
JITコンパイラは、メソッド呼び出しやプロパティアクセスを高速化するため、オブジェクトのハンドラ（`zend_object_handlers`）やプロパティのオフセットをキャッシュする。
もし、JITによって最適化されたコンテキスト内で、前述のような巨大な循環参照構造を持つオブジェクトグラフが頻繁に生成・破棄されると何が起きるか？
1. JITガードの頻繁な無効化（Deoptimization / Bailing out）:
循環参照を持つ複雑なオブジェクトグラフがGCのルートバッファを埋め尽くし、頻繁にGCサイクルが走る。
さらに、動的なプロパティ変更や型情報の揺らぎが発生すると、JITが生成したネイティブコードの「ガード条件」が破られ、JIT空間からインタプリタ（Zend VM）へのフォールバック（Deopt）が多発する。
2. JITメタデータのメモリ断片化（Fragmentation）:
JITバッファ自体は固定長（例: `100M`）である。ガードが無効化され、新しいトレースが生成されるたびに、古いトレースやメタデータは「デッドコード」としてマークされるが、JITバッファ内のメモリ管理は単純なアロケータ（あるいはガーベジコレクションが貧弱なカスタムアロケータ）であるため、フラグメンテーション（断片化）が進行する。
3. GCとJITのデッドロック的競合:
循環参照を持つオブジェクトがメモリ上に居座り続けると、そのオブジェクトが保持するクラス定義、メソッドポインタ、そしてそれらを最適化したJITトレースの参照カウント（あるいは依存関係）が解除されない。
結果として、「オブジェクト本体は循環参照によって回収が遅れ、それに紐づくJITメタデータはOPcacheのバッファ領域を占有し続ける」という、二重のメモリリーク現象（Metadata Leak）が引き起こされる。
—
4. 検証：循環参照とJITメモリ消費のトレース
以下の実用的な検証スクリプトを通じて、Zend VM内部で何が起きているかをシミュレートする。このコードは、意図的に循環参照を高速生成し、OPcache / JIT環境下でのメモリ挙動をあぶり出すためのものである。
/
class JITLeakNode {
public ?JITLeakNode $self_ref = null;
public string $payload;
public function __construct(string $payload) {
$this->payload = str_repeat($payload, 100); // ヒープ消費を増やす
}
// JITのホットスポットとなるメソッド
public function traverse(): int {
$acc = 0;
if ($this->self_ref !== null) {
$acc += strlen($this->self_ref->payload);
}
return $acc;
}
}
function run_cyclic_stress_test(int iterations): void {
echo “— ストレステスト開始 (Iteration: {$iterations}) —\n”;
// 初期メモリ使用量
$initial_memory = memory_get_usage(true);
$initial_real = memory_get_real_usage(true);
for ($i = 0; $i < iterations; $i++) {
$node1 = new JITLeakNode("A");
$node2 = new JITLeakNode("B");
// 意図的な循環参照の構築
$node1->self_ref = $node2;
$node2->self_ref = $node1;
// JITにこのメソッドをコンパイルさせるためのホットコール
for ($j = 0; $j < 100; $j++) {
$node1->traverse();
$node2->traverse();
}
// 変数をスコープから外す（しかし循環参照により即座には解放されない）
unset($node1, $node2);
// 1000回ごとにGCを明示的に強制実行し、メモリの推移を確認
if ($i % 1000 === 0) {
$collected = gc_collect_cycles();
if ($collected > 0) {
// ログ出力（低レイヤの挙動を追跡）
// echo “GC Collected: {$collected} cycles at step {$i}\n”;
}
}
}
$final_memory = memory_get_usage(true);
$final_real = memory_get_real_usage(true);
echo “初期メモリ: ” . number_format($initial_memory) . ” bytes\n”;
echo “最終メモリ: ” . number_format($final_memory) . ” bytes\n”;
echo “実メモリ差分: ” . number_format($final_real – $initial_real) . ” bytes\n”;
echo “ガベージコレクション回収回数（累計）: ” . gc_status()[‘collected’] . “\n”;
}
// 実行
run_cyclic_stress_test(50000);
このコードが低レイヤで意味するもの
上記のスクリプトをJIT有効環境で実行すると、単純なPHPのヒープリーク（`memory_get_usage`で捉えられる値）はGCによってある程度回収される。しかし、OPcacheのJITバッファ内部では、短命なオブジェクト構造に対する過剰なトレース生成により、メタデータの蓄積とキャッシュラインの汚染が発生する。
特に、JITが「このメソッドはポリモーフィズムがない（常に特定のクラスである）」と予測して生成した機械語ガードが、循環参照を含む複雑なオブジェクトライフサイクルによって頻繁に無効化されると、CPUの命令キャッシュ（I-cache）のミスヒット率が跳ね上がり、システム全体のスループットが致命的に低下する。
—
5. 限界突破のためのアーキテクチャ防衛策
Webシステムアーキテクトとして、このJITメタデータリークと循環参照の悪夢を断ち切るためには、コードレベルおよびインフラレベルで以下の極限の対策を講じる必要がある。
A. 弱参照（WeakReference）の積極的活用
PHP 7.4以降で導入された `WeakReference` は、Zend VMレベルで参照カウンターをインクリメントしない特殊な参照ポインタである。親子関係やツリー構造、オブザーバーパターンなど、循環参照が発生しやすいデザインパターンでは、子から親への参照を `WeakReference` に置き換えるべきだ。
class CleanNode {
public ?WeakReference $parent = null;
public function setParent(CleanNode $parent): void {
$this->parent = WeakReference::create($parent);
}
public function getParent(): ?CleanNode {
return $this->parent?->get();
}
}
これにより、循環参照そのものが物理的に成立しなくなるため、GCのアルゴリズムに負荷をかけることがなくなり、JITのガードが無効化されるリスクを最小限に抑えられる。
B. JITバッファとOPcacheのチューニング最適化
高トラフィックな環境では、デフォルトのJIT設定のままではメタデータのフラグメンテーションによってパフォーマンスが劣化する。`php.ini` において、以下のパラメータをワークロードに合わせて厳密にチューニングする必要がある。
[opcache]
opcache.enable = 1
opcache.memory_consumption = 512
opcache.interned_strings_buffer = 64
opcache.max_accelerated_files = 10000
; JIT設定の極意
opcache.jit_buffer_size = 128M
; 125 = 101(全機能有効) だが、型が頻繁に変わるコードベースではトレース生成を抑制するために ‘tracing’ モードを厳格化する
opcache.jit = 1255
opcache.jit_max_root_traces = 2048
opcache.jit_max_polymorphic_calls = 2
特に `jit_max_root_traces` や `jit_max_recursive_calls` が大きすぎると、循環参照や複雑なオブジェクトグラフの変動によって生成された「無駄なトレース」がJITバッファを埋め尽くし、本当に最適化すべきホットスポットの機械語が追い出される（キャッシュブロッティング）原因になる。
—
結びにかえて
PHPのJITコンパイラとZend VMは、もはや単なるスクリプトインタプリタの域を遥かに超越した、極めて高度なコンパイルド・ランタイムである。
その内部挙動を完全に掌握するためには、単に「メモリリークしたから `unset` する」という表層的なアプローチでは不十分だ。循環参照がGCルートを圧迫し、それがJITのインラインキャッシュガードを破壊し、最終的にCPUのI-cache効率やOPcacheの共有メモリ空間を蝕んでいく――この一連の低レイヤの因果関係を視座に収めた者だけが、真にスケーラブルで堅牢なPHP Webシステムを構築できる。
システムアーキテクトよ、コードの表面だけでなく、Zend VMの鼓動を感じ取れ。