PHPジェネレータとFiberのメモリ効率比較：Zend VMのスタック構造とコンテキストスイッチの深層
PHPの進化は、単なるシンタックスの糖衣（Syntactic Sugar）の追加ではない。Zend Engineの内部構造、とりわけメモリ管理と実行コンテキストのライフサイクルは、近年のバージョンアップによって劇的な変貌を遂げた。
ウェブシステムにおける大規模データ処理や非同期I/Oの文脈において、私たちは常に「メモリ」と「CPUキャッシュ効率」のトレードヒートに向き合っている。伝統的な`Generator`（イテレータ）と、PHP 8.1で導入されたスタックレスファイバーである`Fiber`。これらはどちらも処理を中断・再開（Suspend/Resume）させる機構を持つが、Zend VMのメモリ空間上では全く異なる物理構造をとる。
本稿では、Zend VMのオペコード（Opcode）、HashTableの動的アロケーション、そしてコンテキストスイッチのオーバーヘッドという低レイヤの現実から、この2つの機構のメモリ効率を極限まで暴く。
—
1. Zend VMにおけるGeneratorの物理構造とメモリ消費
PHPのジェネレータは、`Generator`クラスのインスタンスとしてユーザーランドに姿を現すが、その実体は通常のオブジェクトとは一線を画す。
オペコードレベルでの状態保持
通常の関数呼び出しは、Zend VM上長でスタックフレーム（`zend_execute_data`）を積み上げ、関数がリターンすればそのメモリは解放される。しかし、`yield`を含む関数は、コンパイル時にZendエディタによって特殊なオペコードへと変換される。
関数が最初に呼び出された時、Zend VMは通常のスタックフレームを構築する代わりに、ヒープ上に `zend_generator` 構造体をアロケートする。ここが重要なポイントだ。ジェネレータの状態（ローカル変数、実行ポインタ、テンポラリ変数のスロット）は、コールスタックではなくヒープ上の専用バッファに退避される。
/
function yield_large_dataset(int $total): Generator {
for ($i = 0; $i < $total; $i++) {
// ローカル変数 $i の状態はヒープ上の zend_generator 内に保持される
yield $i => “data_row_” . $i;
}
}
// 100万件のデータを扱うが、メモリは数バイトのジェネレータ構造体分しか消費しない
$generator = yield_large_dataset(1_000_000);
foreach ($generator as $key => $value) {
// 1行ずつ遅延評価され、GCのサイクルを汚染しない
// 処理が終わったフレームは即座に破棄される
}
メモリ効率の優位性と限界
`Generator`のメモリ効率は圧倒的だ。100万件の配列をメモリ上に展開すれば数十〜数百メガバイトの `zend_array`（HashTable）を消費するが、ジェネレータであれば数キロバイトの構造体オーバーヘッドのみで済む。
しかし、ジェネレータには「単一方向の非同期性」という致命的な構造的制約がある。呼び出し元（Caller）と呼び出し先（Callee）の制御フローは常に密結合しており、コールツリーの深い場所から非同期にイベントを拾い上げるような協調動作（Cooperative Multitasking）は記述できない。
—
2. Fiber（ファイバー）のメモリ構造とコンテキストスイッチ
PHP 8.1で導入された `Fiber` は、PHPに真の協調型マルチタスクをもたらした。Fiberは、任意の場所で実行コンテキストを中断し、別のコンテキストに処理を移譲できる。
`zend_execute_data` のシリアライズと退避
Fiberの内部（Zend Engine Cソースレベル）では、`zend_fiber` 構造体が定義されている。ジェネレータが「自身のローカル変数だけ」をヒープに持つのに対し、Fiberは「コールスタック全体（複数階層の関数呼び出しスタック）」をヒープ上に構築された専用のスタックバッファに退避・復元する。
/
$fiber = new Fiber(function (): void {
$data = “Hello from Fiber”;
// 実行を中断し、親コンテキストへ値を返す
$value = Fiber::suspend($data);
echo “Resumed with: {$value}\n”;
});
// ファイバーを開始し、最初の suspend まで実行
$output = $fiber->start();
var_dump($output); // string(16) “Hello from Fiber”
// ファイバーに値を送り込んで再開
$fiber->resume(“ACK”);
Fiberのメモリコスト
Fiberは非常に強力だが、その代償としてメモリ消費量がジェネレータに比べて圧倒的に大きい。
各Fiberは、独自のCスタック（またはユーザーランドのスタックシミュレーション領域）を確保するため、初期アロケーションコストが発生する。多数のFiberを安易に生成（Thundering Herd問題や数万単位の並行処理）すると、Zendメモリマネージャ（zend_mm）のヒープ断片化を誘発し、結果としてパフォーマンスが急激に劣化する。
—
3. 【核心比較】Generator vs Fiber メモリ効率とユースケースの境界線
| 比較項目 | Generator (イテレータ) | Fiber (ファイバー) |
| :— | :— | :— |
| スタックの範囲 | 単一関数のローカル変数・状態のみ | 複数階層のコールスタック全体 |
| メモリフットプリント | 極小 ($O(1)$、数バイト〜数KB) | 中〜大 (スタックバッファの確保が必要) |
| コンテキストスイッチ | `yield` による単方向の値の返却 | 双方向の制御権移譲 (`suspend`/`resume`) |
| 主な用途 | 大規模データのストリーミング処理 | 非同期I/O、イベントループ、協調型マルチタスク |
大規模データ処理における選択基準
数百万件のデータベースレコードのフェッチや、巨大なCSVファイルのパースにおいて、Fiberを使う理由は皆無である。この領域では、純粋な `Generator` がZend VMのオーバーヘッドを最小限に抑え、CPUキャッシュヒット率を最大化する。
一方、複数のHTTPリクエストを並行して非同期に処理したい場合や、Websocketサーバーのようにイベント駆動で複雑なコールツリーを維持しながら処理を中断・再開する必要がある場合は、`Generator` の単方向の制約では太刀打ちできない。ここで初めて `Fiber` の出番となる。
—
4. セキュリティ・ガバナンス：低レイヤ視点での脆弱性リスク
コア内部のメモリ構造を語る上で避けて通れないのが、これらの非同期・遅延評価機構が絡むセキュリティリスク、特にオブジェクトインジェクション（Object Injection）とGadget Chainの成立である。
シリアライズと動的構造体の罠
PHPの `unserialize()` は、ヒープ上の構造体を復元する際に、マジックメソッド（`__wakeup()` や `__destruct()`）を自動的にトリガーする。
もし、アプリケーションが信頼できない入力をそのままアンシリアライズした場合、攻撃者は巧妙に細工されたバイトストリームを送り込み、意図しないクラスのインスタンスを生成させることができる。
特に、`Generator` やカスタムイテレータ、あるいは閉包（Closure）を含むオブジェクトがシリアライズデータに含まれている場合、Zend VMのメモリ復元プロセスを利用して任意の関数ポインタやメソッド呼び出しの連鎖（Gadget Chain）を構築することが理論的に可能となる。
防御の鉄則
1. 決してユーザー入力をそのまま `unserialize()` しないこと。 代わりに JSON (`json_encode` / `json_decode`) を使用する。JSONはデータ構造のみを復元するため、マジックメソッドやオブジェクトの振る舞いが勝手に実行される余地がない。
2. やむを得ずシリアライズを使用する場合は、`allowed_classes` オプションを厳格に指定し、想定外のクラスロードをZend VMレベルで拒絶する。
// 安全なアンシリアライズの例
$data = unserialize($tainted_input, [‘allowed_classes’ => [App\DTO\SafeDTO::class]]);
—
5. チーフアーキテクトからの提言
PHPはもはや「ただ動くだけのスクリプト言語」ではない。Zend Engineの内部構造を理解し、オペコードとメモリ管理の挙動を脳内で完全にトレースできるエンジニアにとって、PHPは極めて高いパフォーマンスと柔軟性を発揮する強力なプラットフォームである。
- メモリを極限まで節約し、シーケンシャルな大量データを流すなら `Generator`。
- 複雑な非同期フローとコンテキストの保持が必要なら `Fiber`。
この選択基準を誤らぬこと。そして、メモリの裏側で何がアロケートされ、どのように解放されているのかを常に意識し続けること。それが、真にスケーラブルなWebシステムを構築するための唯一にして最大の極意である。