Zend VMの深淵：`zend_object`、参照カウント、そして循環参照GCの物理的真実
PHPを単なる「Webテンプレートエンジン」と捉えているうちは、その真のポテンシャルを引き出すことはできない。我々は常に、数ミリ秒のレイテンシとメモリフットプリントの肥大化と戦うWebシステムアーキテクトである。1リクエストのライフサイクルにおいて、Zend Engineがどれほどの速度でメモリを割り当て、解放し、最適化しているか。その中核を握るのが、オブジェクトのライフサイクル管理機構、すなわち参照カウント（Reference Counting）とガベージコレクション（Garbage Collection）の物理構造である。
今回は、Zend VMの内部構造において、オブジェクトがどのようにメモリ上に存在し、`gc`フラグがどのように生死を決定づけているのか、その極限の知見を紐解いていく。
—
1. プリミティブとオブジェクトの決定的な違い：Zend VMにおけるメモリの非対称性
PHPの変数コンテナである `zval`（Zend Value）構造体は、PHP 7以降、わずか16バイト（64bit環境）にスリム化された。スカラー値（整数や浮動小数点数）は `zval` の内部に値そのものが直に格納（Value Interleaving）されるため、メモリの局所性が高く、キャッシュヒット率も極めて高い。
しかし、オブジェクトはこの原則から外れる。
オブジェクトの実体である `zend_object` は、ヒープ上の別領域に確保され、`zval` はそのポインタを保持する。さらに、オブジェクトが生成されるとき、Zend VMは単にメモリを確保するだけでなく、プロパティを格納するための動的な `HashTable` や、メソッドポインタへの参照テーブルを伴う巨大な構造体を構築する。
ここで重要となるのが、オブジェクトのライフサイクルを追跡するための参照カウントと、それを取り巻く循環参照（Circular Reference）の罠である。
—
2. `gc` フラグの正体：なぜ「緩慢な死」が訪れるのか
PHPのメモリ管理は、基本的にはアトミックな参照カウントによって行われる。変数がコピーされたり、別のスコープに渡されたりすると、`zval`（およびそれが指す `zend_object`）の参照カウンタ（`refcount`）がインクリメントされ、スコープを抜けるとデクリメントされる。`refcount` が `0` に達した瞬間、即座にメモリは解放される。これが最も効率的なメモリ解放メカニズムである。
しかし、オブジェクト同士が互いを参照し合う循環参照が発生した瞬間、この美しい仕組みは破綻する。
child = $b;
$b->child = $a;
// 変数スコープの破棄
unset($a, $b);
上記のコードを実行したとき、$a と $b の `refcount` は、`unset` 後もそれぞれ `1` のこる。なぜなら、$a は $b を指しており、$b は $a を指しているからだ。この状態のメモリは、プロセスが終了するまでゾンビのようにヒープ上に残り続ける。これがメモリリークの正体である。
この自力では `0` にならない循環参照を検出し、死に至らしめるためにZend Engineに組み込まれているのが、三色マーキング法（Tri-color Marking Algorithm）をベースにしたGC（ガベージコレクション）であり、その状態を管理するのが `zend_refcounted_h` 構造体に含まれる `gc` フラグである。
`gc` フラグのライフサイクル状態
Zend VMの内部（`Zend/zend_types.h`）において、すべての参照型データ構造（オブジェクト、配列など）は共通のヘッダを持っている。その中にある `gc` 情報を司るビットフラグは、オブジェクトが現在どのフェーズにあるかを示している。
1. Buffered（バッファリング状態）:
参照カウントがデクリメントされたものの、`0` にならなかったコンテナ（潜在的なガベージ）は、自動的にZendの「GC用の疑わしいバッファ（Roots Buffer）」に送られる。この時、オブジェクトの `gc` フラグには `GC_Buffered` マークが付与される。
2. Purple（紫色：スキャン対象）:
バッファが溢れるか、あるいは明示的に `gc_collect_cycles()` が呼ばれた際、エンジンはバッファ内のオブジェクトをスキャンする。
3. Black / White（黒／白：三色マーキング）:
- 参照を辿りながら到達可能なものは「黒（Active）」に戻す。
- 循環参照の輪の中に閉じ込められ、外部からの参照が一切ないものは「白（Garbage）」として特定され、最終的に破棄される。
—
3. OPcacheプリローディングとオブジェクトの不変性
現代のプロダクション環境において、OPcacheのプリローディング（`opcache.preload`）は、リクエストごとのファイルI/Oとコンパイルコストを極限まで排除するための必須要件である。
しかし、ここでエンジニアが陥りがちな致命的な罠がある。「プリロードされたスクリプト内で初期化されたオブジェクトは、親プロセス（FPMマスター）のメモリ空間に永続化される」という点だ。
// preload.php の例
プリロード空間のオブジェクトは、完全にイミュータブル（不変）として扱わなければならない。
—
4. Fiberとコンテキストスイッチ、そして参照カウントの同期
PHP 8.1で導入された `Fiber`（ファイバー）は、非同期プログラミングのパラダイムを根本から変えた。従来のスタックレスコルーチン（Generator）とは異なり、Fiberは独立したコールスタックを持ち、VMの実行コンテキスト（`zend_execute_data`）を任意のタイミングで中断・再開できる。
ここで低レイヤのアーキテクトとして懸念すべきは、「Fiberのサスペンド（中断）とレジューム（再開）の間における、オブジェクトの参照カウントとGCの整合性」である。
Fiberの内部で生成され、まだスコープ内にあるオブジェクトへの参照は、Fiberがサスペンドしている間、コールスタック（`execute_data` のツリー）上に保持され続ける。つまり、親のイベントループ側でそのFiberインスタンスへの参照を失わない限り、Fiber内のローカルオブジェクトの `refcount` は維持され、GCのルートバッファに誤検知されて回収されることはない。
しかし、Fiberを跨いだグローバルな状態共有を行う場合、循環参照の発生リスクは爆発的に跳ね上がる。非同期処理のコンテキストが複雑に絡み合うコードベースでは、意図しないクロージャのキャプチャによってオブジェクトのライフサイクルが肥大化し、メモリリークの温床となる。
—
5. セキュリティハック：オブジェクトインジェクションとGadget Chainの構造的必然
ここまでZend VMのオブジェクト管理の裏側を解説してきたが、このメモリモデルとライフサイクルの挙動は、セキュリティ脆弱性である「PHPオブジェクトインジェクション（PHP Object Injection）」のメカニズムを理解する上での鍵となる。
悪意ある攻撃者が `unserialize()` に任意の文字列を流し込める脆弱性（CWE-502）が存在する場合、何が起きるのか？
Zend VMのシリアライゼーション機構は、渡されたバイトストリームをパースし、指定されたクラス名の `zend_class_entry` をルックアップして、ヒープ上に強制的に `zend_object` を再構築する。この瞬間、コンストラクタは呼ばれないが、デストラクタやマジックメソッド（`__wakeup()`, `__destruct()`）は容赦なく実行される。
攻撃者は、アプリケーション内に存在する既存のクラス群（Gadget）をパズルピースのように組み合わせ、`unserialize()` によって不正なオブジェクトグラフ（循環参照や悪意あるプロパティを持つオブジェクトツリー）をメモリ上に一瞬で構築する。
[悪意あるシリアライズデータ]
↓ (unserialize)
Zend VM ヒープ上にオブジェクトグラフが強制構築
↓
スクリプト終了時 (またはGCの走査時 / デストラクト時)
↓
__destruct() や __toString() が連鎖発火 (Gadget Chain Execution)
↓
リモートコード実行 (RCE) の達成
防御の要諦は、信頼できない入力を絶対に `unserialize()` に渡さないこと、そしてPHP 7.0以降で導入された `allowed_classes` オプションを厳格に適用することだ。Zend VMの内部仕様を熟知した攻撃者にとって、オブジェクトのメモリ配置とガベージコレクションの挙動は、まさに「自らのコードを実行するための踏み台」に他ならない。
—
結びにかえて：エンジンの鼓動を聞け
PHPは「動的で手軽な言語」で片付けられるフェーズを遠に過ぎ去った。Zend VMの低レイヤ構造、メモリ空間の割り当て、参照カウントの増減、そしてGCのフラグ制御までを脳内で完全にシミュレートできる者だけが、真にスケーラブルで堅牢なWebシステムを設計・構築することができる。
コードを書くときは、常に背後で動いているZend Engineの鼓動を感じろ。あなたが生成したその `new` は、ヒープのどこを揺らし、いつどのように消えていくのか。その全権を掌握したとき、あなたの書くコードは、限界を突破した超高効率なシステムへと昇華する。