PHP 8.x Fiberにおけるコルーチンスタックのメモリ管理とガベージコレクションの相互作用
PHP 8.1における `Fiber`（ファイバー）の導入は、PHPにおける非同期並行処理のパラダイムシフトをもたらした。従来、I/Oバウンドな処理の並行化には、多重プロセス、非同期拡張機能（Swoole, ReactPHP等）、あるいはマルチスレッド（pthreads）という複雑なアプローチが必要だった。Fiberは、言語コアレベルで協調的マルチタスク（Cooperative Multitasking）を実現するスタックフル・コルーチンである。
しかし、Zend VMの内部構造、特にメモリ管理機構（ZendMM）およびガベージコレクション（GC）との相互作用を理解せずにプロダクション環境へ投入することは、予期せぬメモリリークやセグメンテーション違反を誘発する爆弾を抱えるに等しい。本稿では、Fiber生成時のスタック領域の物理的確保、実行コンテキストのスイッチング、そしてZend GCがFiberライフサイクルに及ぼす影響を、低レイヤの視点から徹底的に解剖する。
—
1. Zend VMにおけるFiberスタックの物理構造とメモリ確保
従来の関数呼び出しは、コールスタック（CスタックおよびZend VMの実行スタック）上で線形に積まれ、リターン時に破棄される。しかし、Fiberは「中断（Suspend）」と「再開（Resume）」を任意の深さのコールスタックから行う必要がある。そのため、Fiberごとに独立した仮想的なコールスタック領域がヒープ上に確保される。
Fiber生成時のメモリ割り当て
Zend Engine（Zend/zend_fibers.c）において、FiberはオペレーティングシステムのファイバーAPI（WindowsならFiber API、POSIX系なら `ucontext_t` や Boost.Context等に類似する仕組み）あるいは独自のアセンブリベースの実装（Boost.Contextベース）を用いてコンテキストを管理している。
Fiberインスタンスが生成される際、ZendMMは以下のメモリブロックを確保する：
1. `zend_fiber` 構造体：Fiberの状態、コールバック関数、クロージャ、フラグなどを保持するメタデータ。
2. スタックバッファ：ユーザースペースの実行スタック（デフォルトでは通常64KB〜数MBの範囲でプラットフォーム依存、あるいはZendのデフォルト設定に依存）。
/ 概念的なZend内部構造のイメージ（C言語レベルの解釈） /
typedef struct _zend_fiber {
zend_object standard;
zend_fiber_status status;
zend_fcall_info fci;
zend_fcall_info_cache fci_cache;
// コルーチンスタックのポインタとサイズ
void stack;
size_t stack_size;
// 実行コンテキスト
zend_fiber_transfer context;
// …
} zend_fiber;
このスタックバッファは、ZendMMのヒープ上（あるいはシステムアロケータ）に確保されるため、PHPの通常のスクリプト変数と同様に、スクリプトのメモリ制限（`memory_limit`）の監視下にある。多数のFiberを同時並行で起動（数万〜数十万規模）させる場合、このスタックサイズがメモリ枯渇（Out of Memory）の主因となる。
—
2. コンテキストスイッチングとOPcache・オペコード実行の軌跡
Fiberが `Fiber::suspend()` を呼び出した瞬間、Zend VMは何を行っているのか。
通常のリクエストライフサイクルでは、Zend VMはエクスクルーシブにプレースホルダ（`EG(current_execute_data)`）を更新しながらオペコードを順次実行していく。Fiberのコンテキストスイッチが発生すると、以下の低レイヤ処理が実行される。
1. 現在の実行コンテキストの退避：
現在の `zend_execute_data` ポインタ、VMのレジスタ状態、ローカル変数の参照がFiberのスタック構造体に保存される。
2. 親コンテキストへの復帰：
Fiberを呼び出した側（メインの実行コンテキスト）の `zend_execute_data` が `EG(current_execute_data)` に再設定される。
3. 制御の移譲：
PHPスクリプトの実行フローは、`Fiber::suspend()` の呼び出し元へ即座に復帰する。
この仕組みにより、非同期I/O待ちの間に別のFiberへ処理を切り替えることが可能になるが、ここで重要なのは「スタック上に保持されているローカル変数やオブジェクトへの参照が、GCの追跡からどのように隠蔽されるか」という点である。
—
3. 循環参照とガベージコレクション（GC）の罠
PHPのメモリ管理は、主にリファレンスカウント（Reference Counting）によって行われており、循環参照が発生した場合には三色マーキング法に基づく循環ガベージコレクタ（GC）がそれを回収する。
Fiberの内部で動作するクロージャやローカル変数が、外部スコープのオブジェクトと複雑な循環参照を形成した場合、Fiber自体のライフサイクルとGCのインタラクションに注意が必要となる。
危険なパターン：Fiber内部からの外部スコープ参照とクロージャ
以下のPHPコードを見てみよう。
data = str_repeat(‘A’, 1024 1024); // 1MBのペイロード
$holder->fiber = new Fiber(function () use ($holder) {
// $holder をクロージャでキャプチャし、さらにFiber自身が$holderに保持されている
Fiber::suspend();
echo “Fiber resumed, data length: ” . strlen($holder->data) . “\n”;
});
$holder->fiber->start();
// ここで $holder を明示的にunsetしても、循環参照が成立しているため即座には解放されない
// unset($holder);
内部で何が起きているか（Zend VM & GCの視点）
1. `$holder` は `ResourceHolder` インスタンスを指す。
2. `ResourceHolder::$fiber` は `Fiber` オブジェクトを指す。
3. `Fiber` の内部クロージャ（`fci`/`fci_cache`）は、`use ($holder)` を通じて元の `$holder` への強参照（Refcount +1）を保持している。
4. 結果として、`$holder -> Fiber -> クロージャ -> $holder` という強参照の循環（Circular Reference）が形成される。
もし `$holder = null;` とスコープを外したとしても、リファレンスカウントは0にならない。この状態のFiberが「中断（Suspended）」状態で放置された場合、スタック領域および関連するすべての変数はヒープ上に保持され続けたまま、GCのバッファ（Circular Buffer）に回収候補として登録されるのを待つことになる。
FiberライフサイクルとGCルートバッファ
Zend GCは、リファレンスカウントが減少したものの0にならなかった変数をルートバッファに追加する。しかし、中断されたFiberのコールスタック上に存在するローカル変数や一時変数は、通常のルートスキャンから見落とされやすいケースがある。特に、Cレベルのスタック領域に隠蔽されたZend値（`zval`）の参照カウンタが正確に追跡されない場合、メモリリーク（あるいは解放タイミングの遅延）を引き起こす。
プロダクション環境で大量のFiberを生成・破棄するアーキテクチャ（例えば、数万のリクエストを処理する非同期HTTPサーバー）において、この循環参照のリークが蓄積すると、短時間で `memory_limit` に到達し、致命的なプロセス停止を引き起こす。
—
4. OPcacheプリローディングとFiberの相性
PHP 7.4以降導入されたOPcacheプリローディング（Preloading）は、スクリプト開始時に指定したファイルをメモリ上に常駐させ、クラス定義や関数をパース済みのオペコードとして共有メモリ（SHM）にロードする機能である。
Fiberのコールバックとして渡されるクロージャやクラスメソッドがOPcacheによってプリロードされている場合、パフォーマンス上の大きな恩恵を受けられる。しかし、以下の点にアーキテクトとして留意すべきである。
- 共有メモリ上の構造体とFiberスタックの分離：
オペコードやクラスの構造体はOPcacheの共有メモリ（SHM）上に配置されるため、プロセス間で共有される。一方、Fiberが保持するインスタンス変数の値（プロパティ）やコールスタック上のローカル変数は、プロセス固有のヒープ（ZendMM）上に動的に確保される。
- プリロードされたクラスのインスタンスをFiber内で生成・操作する場合、メモリの割り当て先はプロセス固有ヒープであるため、Fiberのコンテキストスイッチに伴うオーバーヘッドは最小限に抑えられるが、プロセス間でのメモリ共有にはならない点に注意が必要である。
—
5. セキュリティ・観点：オブジェクトインジェクションとFiberのコンテキスト
PHPにおけるセキュリティ脆弱性の代表格である「PHPオブジェクトインジェクション（PHP Object Injection）」や「Gadget Chain」の文脈において、Fiberの導入は攻撃者にとって新たなアプローチを生む可能性を秘めている。
通常、オブジェクトインジェクションの脆弱性は、`unserialize()` の実行時に意図しないクラスの `__destruct()` や `__wakeup()` が呼び出されることでトリガーされる。ここにFiberが絡む場合、次のような高度な攻撃ベクトルが想定される。
Gadget Chainの持続化と非同期実行
悪意あるシリアライズデータに、悪意あるクロージャを内包した `Fiber` インスタンスが含まれていた場合：
1. `unserialize()` によって `Fiber` オブジェクトおよびそれに関連するオブジェクトグラフが再構築される。
2. 攻撃者がマジックメソッドを通じてFiberの自動実行（あるいは意図的な `resume()` の誘発）に成功した場合、中断されていた非同期コンテキストが意図しないタイミングで再開される。
3. これにより、従来の直線的なコールスタックの制約をバイパスし、任意のオペコード列を非同期的に実行する「非同期Gadget Chain」が成立するリスクが生じる。
防御策（Defense in Depth）
- 未検証データのデシリアライズの排除：ユーザー入力を直接 `unserialize()` に渡さない。JSON（`json_encode`/`json_decode`）や安全なシリアライザを使用する。
- Fiberインスタンスのシリアライズ禁止：PHPの `Fiber` オブジェクトは内部のCレベルのコンテキストポインタや関数ポインタを保持しているため、原則としてシリアライズ不可能（Serialization of ‘Fiber’ is not allowed）である。しかし、Fiberを内包するカスタムオブジェクトが誤ってシリアライズされないよう、`__sleep()` や `__serialize()` マジックメソッドで適切にフィルタリングすること。
class SecureContextHolder {
private ?Fiber $fiber = null;
public function __serialize(): array {
// Fiberオブジェクトのシリアライズを完全にブロック
throw new \LogicException(“Fibers cannot be serialized.”);
}
public function __unserialize(array $data): void {
throw new \LogicException(“Fibers cannot be unserialized.”);
}
}
—
6. チーフアーキテクトからの提言：Fiber運用の極意
高スループットなWebシステムにおいてFiberを極限まで活用するための指針を以下にまとめる。
1. スタック消費量の見積もりと最適化：
デフォルトのスタックサイズが大きい場合、数千のFiberを起動するだけで数GBのメモリを消費する。不要な深すぎる再帰呼び出しや、巨大な変数のスタック上での保持を避け、必要に応じてストリーミング処理を組み合わせること。
2. 循環参照の厳格な排除（WeakReferenceの活用）：
Fiberのクロージャ内で外部オブジェクトをキャプチャする際は、強参照を避け、可能な限り `WeakReference` を用いてGCの回収を妨げない設計を徹底する。
$weakHolder = WeakReference::create($holder);
$fiber = new Fiber(function () use ($weakHolder) {
$holder = $weakHolder->get();
if ($holder === null) {
return; // オブジェクトがすでに解放されている場合は安全に終了
}
Fiber::suspend();
});
3. イベントループとの統合における例外処理：
Fiber内で発生した未キャッチの例外（Uncaught Exception）は、現在の実行コンテキストを崩壊させ、Fiberを「terminated」状態にする。イベントループ側で確実に例外を捕捉し、メモリリークやリソースの解放漏れ（オープンファイルハンドルのリークなど）を防ぐエラーハンドリングパイプラインを構築すること。
PHP 8.xのFiberは、単なるシンタックスシュガーではなく、Zend VMの実行モデルに深く踏み込んだ強力なプリミティブである。その低レイヤの挙動、メモリ管理のメカニズム、そしてGCとの相互作用を完全に掌握した者だけが、真にスケーラブルで堅牢な非同期PHPアーキテクチャを構築できる。