Zend Engine 3.0以降のGC最適化：世代別GCと参照カウントの協調動作がもたらすメモリ管理の極限
PHPは、Webの急速なスケール要求に応える中で「動的言語の書きやすさ」と「ミリ秒単位の処理速度」の果てしないトレードオフを戦い抜いてきた。その中核に君臨するのが Zend VM である。
世間一般のPHP解説記事では、「変数は `zval` という構造体に値が入る」「GCが自動でメモリを掃除してくれる」といった抽象論で語られがちだ。しかし、高負荷なプロダクション環境において、数百万のオブジェクトを生成・破棄するリクエストを捌くアーキテクトにとって、Zend Engine内部のメモリ空間（HashTable）がどう呼吸し、キャッシュラインをどう汚染しているかの理解は不可欠である。
本稿では、Zend Engine 3.0（PHP 7以降）で劇的な進化を遂げた世代別GC（Generational GC）と参照カウントの協調動作に焦点を当て、PHPのメモリ管理の極限を低レイヤの視点から剥き出しにする。
—
1. 参照カウントの限界とZend Engine 3.0のパラダイムシフト
PHPのすべての変数は、C言語レベルで `zval`（Zend Value）という構造体として表現されている。PHP 5時代、メモリ解放の基本は純粋な参照カウント方式（Reference Counting）だった。
typedef struct _zval_struct zval;
struct _zval_struct {
zend_value value;
union {
struct {
ZEND_ENDIAN_LOHI_4(
zend_uchar type,
zend_uchar type_flags,
zend_uchar const_flags,
zend_uchar reserved)
} v;
uint32_t type_all;
} u1;
union {
uint32_t next;
uint32_t cache_slot;
uint32_t oas_ptr,
uint32_t gc_info;
} u2;
};
`zval` のサイズはPHP 7で劇的に縮小（64bit環境で24バイトから16バイトへ）され、L1/L2キャッシュへのヒット率が最適化された。しかし、参照カウントには致命的な弱点がある。それが「循環参照（Circular Reference）」だ。
オブジェクトAがオブジェクトBを参照し、オブジェクトBがオブジェクトAを参照している場合、外部からの参照を断っても、お互いの参照カウントは `1` 残ったままになる。これがメモリリークを引き起こす。
PHP 5では、この循環参照を検知するために「バッファに溜まった候補を全走査して減算し、カウントが0にならなかったら元に戻す」という非常に重いアルゴリズム（Concurrent Cycle Collection）が動いていた。これが、複雑なオブジェクトグラフを持つアプリケーションのパフォーマンスを急激に低下させるボトルネックとなっていた。
—
2. 世代別GC（Generational GC）のメカニズム
Zend Engine 3.0以降、この古くからの問題に対する解答として導入されたのが、世代別GCの概念を応用したバッファリングとルート緩衝の最適化である。
メモリ管理の基本原則である「大半のオブジェクトは短命である（Weak Generational Hypothesis）」という統計的事実を、Zend EngineはPHPのコンテキストに持ち込んだ。
ルートバッファと色の三色標識（Tri-color marking）の進化
Zend EngineのGCは、すべての `zval` を常時監視しているわけではない。配列（Array）やオブジェクト（Object）など、コンテナ型となり得る `zval` が「参照カウントがデクリメントされたが、まだ0になっていない」という状態に陥ったとき、それらをGCのルートバッファ（Candidate Buffer）に一度だけ登録する。
1. Buffer (Root): 疑わしい循環参照の候補が溜まる。
2. Purple (紫): 循環参照の可能性がある状態としてマークされる。
3. Grey/White/Black: 探索フェーズにおいて、到達可能性を判定する。
ここで世代別の最適化が効いてくる。短命なオブジェクトは、GCが本格的なスキャン（重いサイクル検出アルゴリズム）を走らせる前に、リクエスト終了とともにOS（またはZendメモリマネージャ）へ一括返却される。
つまり、長期間生存しているオブジェクト（例えば、DIコンテナに保持されたシングルトンや静的プロパティ）と、1回のリクエスト内で消え去る一時的なオブジェクトが混在する空間において、世代別の概念（＝スキャン頻度の動的調整）により、「すでに死んでいると分かっている長寿命オブジェクトを何度も再スキャンする無駄」を極限まで排除しているのである。
—
3. OPcacheプリローディングとメモリ空間の物理構造
GCの動作を語る上で欠かせないのが、PHP 7.4で導入されたOPcacheプリローディング（Preloading）だ。
通常、PHPはリクエストごとにスクリプトをパースし、AST（抽象構文木）を生成し、Zend VMのOpcodeにコンパイルする。しかしプリローディングを使用すると、サーバ起動時（`php-fpm` のマスタープロセス起動時）に指定したスクリプト群がメモリ上にコンパイルされ、共有メモリ（SHM）に常駐する。
ここで重要なのは、プリロードされたクラスの `zval` や関数テーブルは、フォークされたワーカープロセス間でCopy-on-Write（COW）によって共有されるという点だ。
[ PHP-FPM Master Process ]
└─ OPcache Shared Memory (SHM)
├─ Preloaded Classes (AST / Opcode / zval) <-- COWで各ワーカーから参照
└─ ...
│
├─ [ Worker Process 1 ] (Request 1) -> ローカルヒープでの動的zval操作・GC発生
└─ [ Worker Process 2 ] (Request 2) -> ローカルヒープでの動的zval操作・GC発生
このアーキテクチャにおいて、世代別GCと参照カウントは、共有メモリ領域の汚染を防ぐ防壁としても機能する。プリロードされたクラスの構造体に循環参照が含まれていた場合、マスタープロセス側で初期化時に適切に解決・または不変データとして固定化されないと、ワーカープロセスがリクエストを処理するたびにCOWが発生し、メモリ効率が台無しになる。
—
4. 悪夢の構文：オブジェクトインジェクションとGCの隙間
さて、低レイヤのメモリ管理を極めるエンジニアであれば、このZend Engineのメモリ操作モデルが、セキュリティインシデントにおいてどのように悪用されるかも知っておく必要がある。
PHPにおけるオブジェクトインジェクション（Object Injection）は、信頼できないデータに対して `unserialize()` を実行することで、攻撃者が任意のクラスのインスタンスを生成し、`__wakeup()` や `__destruct()` などのマジックメソッドを暴走させる脆弱性である。
近年の高度な攻撃では、単にマジックメソッドを呼ぶだけでなく、ガジェットチェーン（Gadget Chain）を構築し、Zend Engineのメモリ解放フェーズやGCの挙動の隙間を突くケースが存在する。
脆弱なコードの典型例
logFile = $file;
$this->logData = $data;
}
// デストラクターでファイルを書き込む（ガジェットの起点になりやすい）
public function __destruct() {
// 危険なファイル書き込みのシミュレーション
file_put_contents($this->logFile, $this->logData, FILE_APPEND);
}
}
// ユーザーからの未検証の入力をそのままデシリアライズする
$userInput = $_POST[‘payload’] ?? ”;
$obj = unserialize($userInput);
ガジェットチェーンとメモリのライフサイクル
1. 攻撃者は、`unserialize()` を通じて、悪意あるプロパティを持つオブジェクトを強制的に構築する。
2. デシリアライズ処理中、Zend Engineはヒープ上に `zval` を展開し、参照カウントを構築していく。
3. リクエストの終了時、または変数がスコープアウトした際、参照カウントが `0` に達したオブジェクトから順にデストラクター（`__destruct()`）が同期的に呼び出される。
最高峰のセキュリティハックや防御においては、「Zend VMがどの順序で `zval` の参照を断ち、どのタイミングでデストラクターのopcodeを実行するか」を完全に把握していなければならない。悪意あるペイロードが複雑な循環参照を内包している場合、GCのサイクル検出とデストラクターの実行順序の揺らぎを利用して、本来意図しないメモリ状態やリソース競合を引き起こす高度なエクスプロイトも理論的には成立し得る。
—
5. Fiberによる並行処理とメモリコンテキストの分離
PHP 8.1で導入された Fiber（ファイバー / 軽量スレッド） は、非同期処理パラダイムをPHPに持ち込んだ。コールバック地獄から解放された一方で、メモリ管理の観点からは新たな考慮事項が生まれた。
従来のPHPは「1リクエスト = 1プロセス（または1スレッド）」であり、コールスタックはOSのスタック、あるいはZend VMの限定的な実行スタックで完結していた。しかし、Fiberはユーザースペースでのスタック切り替え（コンテキストスイッチ）を実現する。
start();
echo “Main: {$output}\n”;
$fiber->resume(‘Hello from Main’);
このコードの裏側で、Zend EngineはFiberごとに個別の実行スタック（`zend_execute_data` のチェーン）をヒープ上に割り当てている。
- メモリリークの危険性: Fiber内で生成されたローカル変数やオブジェクトが、中断（suspend）状態のまま参照を維持し続けると、そのFiberインスタンス自体が破棄されない限り、参照カウントは減少しない。
- GCのスコープ: 世代別GCはリクエスト全体（あるいはグローバルなZendメモリマネージャ）のコンテキストで動作するため、長寿命のFiberプールを非同期サーバー（ReactPHPやAmp等）上で運用する場合、Fiber間の参照循環を見逃すと、プロセス全体のメモリ使用量が右肩上がりに高騰するメモリリークの温床となる。
Fiberを使うエンジニアは、単に「非同期で書ける」という表層的なメリットだけでなく、「コンテキストスイッチが発生した瞬間に、どの `zval` のライフサイクルが一時停止し、どのメモリがヒープ上にピン留めされるか」を脳内で正確にトレースできなければならない。
—
結び：限界を突破するアーキテクトへ
PHPは「遅い言語」という神話は、Zend Engine 3.0以降の最適化、OPcache、そしてJIT（Just-In-Time Compiler）の導入によって完全に過去のものとなった。
しかし、フレームワークが提供する抽象化の厚い層の向こう側では、依然としてC言語で書かれたZend VMがミリ秒単位のメモリ操作を淡々と実行し続けている。
世代別GCの仕組み、参照カウントと循環参照の攻防、OPcacheプリローディングのCOW構造、そしてFiberのスタック管理——これらすべての低レイヤの振る舞いを掌握した者だけが、トラフィックの嵐の中でも微動だにしない、真に堅牢で爆速なWebシステムを設計・構築することができる。
コードの向こう側にあるZend Engineの鼓動を感じ取れ。それが、真のPHPアーキテクトの姿である。