PHPジェネレータとFiberのメモリ効率：遅延評価の裏側とZend VMの限界領域
PHPの進化は、単なる構文の糖衣（シンタックスシュガー）の追加ではない。Zend VM（Zend Engine）のメモリ管理、オペコード（Opcode）の実行フロー、そしてスタックフレームの扱いは、バージョンを重ねるごとに劇的な変貌を遂げてきた。
大規模データ処理や非同期・並行処理において、しばしば比較の俎上に載せられるのが Generator（ジェネレータ） と Fiber（ファイバー） である。これらはどちらも「処理を中断・再開する」という共通の特性を持つが、その内部アーキテクチャ、メモリフットプリント、そしてZend VM上での生存戦略は全く異なる。
本稿では、Zend VMの低レイヤ構造、zend_execute_dataのメモリ配置、そして両者の遅延評価メカニズムを解剖し、高負荷環境における真のリソース効率の最適解を導き出す。
—
1. Zend VMにおける実行コンテキストの基本構造
ジェネレータとFiberの挙動を理解するには、まずPHPが関数呼び出しや制御構文をどのように処理しているかを知らなければならない。
PHPの関数やメソッドが実行されるとき、Zend VMはコールスタック上に `zend_execute_data` と呼ばる構造体をアロケートする。この構造体には以下の情報が詰まっている。
- 現在実行中のオペコード配列（`zend_op_array`）へのポインタ
- プログラムカウンタ（`opline`）
- ローカル変数や一時変数のためのシンボルテーブル（あるいはプレースホルダー）
- 呼び出し元の `zend_execute_data` へのポインタ（`prev_execute_data`）
通常、関数がリターンすると、この `zend_execute_data` は即座に解放（あるいはフリーリストに返却）される。しかし、ジェネレータ と Fiber は、このスタックフレームの寿命を引き伸ばす、あるいは別のヒープ領域へ退避させるという特異なアプローチを取る。
—
2. ジェネレータ（Generator）：スタックレスコルーチンと遅延評価の省メモリ性
内部構造とメモリ配置
Generatorは、PHP 5.5で導入されて以来、メモリ効率の良いデータ処理の代名詞となっている。内部的には `zend_generator` というC言語の構造体としてヒープ上に生成される。
数百万件のレコードをデータベースからフェッチし、処理するシナリオを考えてみる。全件を配列（`array`）としてメモリ上に展開した場合、Zendの `HashTable` 構造体と各zvalのオーバーヘッドにより、数ギガバイトのメモリが瞬時に蒸発する。
一方、Generatorは `yield` キーワードに到達するたびに、その時点のローカル変数と実行状態を `zend_generator` オブジェクト内に保持し、呼び出し元へ制御を返す。
/
function streamLargeDataset(int $totalRows): Generator
{
for ($i = 1; $i <= $totalRows; $i++) {
// 各反復で生成されるデータは、yieldの瞬間に評価され、即座にコンテキストが退避される
yield $i => [
‘id’ => $i,
‘payload’ => hash(‘sha256’, (string)$i),
‘timestamp’ => microtime(true),
];
}
}
// 100万件であっても、メモリ消費量はほぼフラット（数キロバイトオーダー）を維持する
$generator = streamLargeDataset(1_000_000);
foreach ($generator as $id => $row) {
// 1行ずつ遅延評価（Lazy Evaluation）で処理
// Zend VMはループのたびにzend_generatorのポインタを進める
if ($id > 3) {
break; // 途中で破棄すれば、残りのデータは一切生成されない
}
}
ジェネレータの限界
Generatorは「スタックレス（Stackless）」である。つまり、自身が呼び出した別の通常の関数（子関数）の内部から直接 `yield` することはできない（PHP 7以降の `yield from` による委譲はあるものの、あくまでイテレータのチェインであ真のスタック分離ではない）。
メモリ効率は極めて高いが、表現できる並行処理や制御フローの自由度は、あくまで「一方向に流れるイテレータの拡張」に留まる。
—
3. Fiber（ファイバー）：スタックフルコルーチンとコンテキストスイッチのコスト
PHP 8.1で導入されたFiberは、ゲームチェンジャーとなった。Fiberは「スタックフル（Stackful）コルーチン」であり、コールスタックの任意の深さから処理を中断（Suspend）し、任意の場所から再開（Resume）できる。
Fiberのメモリ構造とZend VMへの影響
Fiberを生成すると、Zend VMは通常のコールスタックとは別に、Fiber専用のスタック領域（ヒープ上にアロケートされた `zend_execute_data` のチェーン）を保持する。
これにより、非同期I/Oやイベントループ（AmpやReactPHPなどの基盤）において、コールバック地獄（Pyramid of Doom）を回避しながら同期的なコードスタイルで非同期処理を書くことが可能になった。
しかし、この柔軟性には明確な「コスト」が存在する。
declare(strict_types=1);
/
- Fiberを用いた非同期タスクの模倣
- Fiberは独自のコールスタックを持つため、ジェネレータよりもメモリフットプリントが大きい
/
function executeAsyncOperation(int $id): Fiber
{
return new Fiber(function (string $taskName) use ($id): void {
echo “Fiber #{$id} ({$taskName}) 開始\n”;
// 処理を中断し、呼び出し元へ制御を返す（スタックフレームは保持されたまま）
$data = Fiber::suspend(“Fiber #{$id} からの中断データ”);
echo “Fiber #{$id} 再開。受け取ったデータ: {$data}\n”;
});
}
// Fiberのインスタンス化（この時点で専用の実行コンテキスト構造体がアロケートされる）
$fiber = executeAsyncOperation(1);
// 開始
$output = $fiber->start(‘NetworkRequest’);
echo “メインスレッド受信: {$output}\n”;
// 再開とデータの注入
$fiber->resume(‘DB Connection Established’);
メモリ消費の比較：Generator vs Fiber
| 特性 | Generator (ジェネレータ) | Fiber (ファイバー) |
| :— | :— | :— |
| スタックの種類 | スタックレス（単一のフレーム退避） | スタックフル（独自のコールスタックチェーン） |
| メモリフットプリント | 極小（数バイト〜数KB） | 中程度〜大（スタックサイズ分のヒープ消費） |
| 主な用途 | 大規模データの遅延評価・ストリーミング | 非同期I/O、タスクスケジューリング、並行処理 |
| コンテキストスイッチ | 高速（単一オブジェクトの状態更新） | やや重い（スタックポインタの切り替えとVMステータスの退避） |
Fiberは強力だが、「すべての関数呼び出しをFiberで行う」ような設計をとると、通常の関数呼び出しと比較してZend VMのヒープアロケーション頻度が増加し、ガベージコレクションやメモリ管理のオーバーヘッドが無視できなくなる。
—
4. OPcacheプリローディングと低レイヤ最適化の視点
高スループットが求められるWebシステムにおいて、これら遅延評価や並行処理の機構を本番稼働させる際、OPcacheプリローディング（Preloading） との兼ね合いを考慮しなければならない。
PHP 7.4で導入されたOPcacheプリローディングは、サーバー起動時に指定したスクリプト群をパースし、オペコード（`zend_op_array`）を共有メモリ（SHM）上に永続化する。これにより、リクエストごとのファイルI/Oとパースコストがゼロになる。
しかし、GeneratorやFiberの内部で動的に生成されるインスタンスや、実行中の `zend_execute_data` の状態は共有メモリ上には乗らない。 これらはリクエストごとに変化する「動的ステート」であるため、プロセス固有のヒープ（Zend Memory Manager）上にアロケートされる。
したがって、以下のアーキテクチャ設計が極限のパフォーマンスを引き出す鉄則となる。
1. 静的なロジックのプリロード:
ジェネレータのロジックを持つクラスや、Fiberをラップするスケジューラーのクラス群は完全にOPcacheのプリロード対象に含め、オペコードキャッシュのヒット率を100%に近づける。
2. メモリリークの厳禁（C言語レベルの視点）:
FiberやGenerator内で循環参照（Circular Reference）が発生した場合、Zend VMの参照カウンティング（Reference Counting）だけでは回収しきれず、ガベージコレクタ（GC）のサイクル回収に依存することになる。高頻度でこれらを生成・破棄するワーカープロセスでは、意図しないメモリリークがFPMプロセスの寿命を縮める原因となる。
—
5. セキュリティハックの文脈：オブジェクトインジェクションと実行コンテキストの危険性
ここまでの低レイヤの知見（Zend VMのメモリ構造、オブジェクトの永続化、ステートの保持）は、攻撃者にとっても極めて魅力的な領域である。
PHPセキュリティにおいて最悪の脆弱性の一つである PHPオブジェクトインジェクション（PHP Object Injection） は、まさにこの `zend_generator` やカスタムイテレータ、あるいはFiberの内部状態を利用したGadget Chain（ガジェットチェーン）の構築に悪用されることがある。
ガジェットチェーンのメカニズム
もしアプリケーションが信頼できないユーザー入力を `unserialize()` に渡していた場合、攻撃者はマジックメソッド（`__destruct`, `__wakeup`, `__toString` など）を持つ既存のクラスを連鎖させ、任意のコード実行（RCE）を引き起こす。
特に、内部でイテレータや遅延評価を行うオブジェクトが悪用されるケースでは、デシリアライズの過程でZend VMのオペコード実行フローが歪められ、意図しないメソッドが意図しないタイミングで呼び出される。
/
- 【警告】セキュリティ脆弱性の概念実習コード（安全な環境・検証目的以外での使用厳禁）
- 悪意あるデシリアライズにより、遅延評価オブジェクトの内部ステートが改ざんされる危険性
/
class MalformedIteratorAggregate implements IteratorAggregate
{
private string $callback;
private array $params;
public function __construct(string $callback, array $params)
{
$this->callback = $callback;
$this->params = $params;
}
// デシリアライズ時やイテレーション時に自動実行されるマジックメソッド群が
// 攻撃者によってGadget Chainの起点として悪用される
public function getIterator(): Traversable
{
if (is_callable($this->callback)) {
// 危険なコールバックの実行（RCEの温床）
call_user_func($this->callback, …$this->params);
}
return new ArrayIterator([]);
}
}
防御の極意
1. `unserialize()` の完全排除:
現代のWebシステムにおいて、外部入力を `unserialize()` する必要性は皆無に近い。JSON（`json_encode` / `json_decode`）を使用するべきである。
2. 型安全性の強制:
プロパティの型宣言や `__unserialize()` / `__serialize()` マジックメソッド（PHP 7.4+）を使用し、デシリアライズ時の挙動を厳格に制御する。
—
6. 結び：エンジニアが選ぶべき最適解
PHPのGeneratorとFiberは、どちらもZend VMの実行コンテキストを巧みに操る強力な武器である。
- 大規模なデータのストリーミング、メモリバッファの枯渇を防ぎたい場合：
迷わず Generator を選択せよ。スタックレスの軽量性が、数百万件のレコード処理を極限まで省メモリで完遂させる。
- 非同期I/Oや、処理の細やかな中断・再開を伴う複雑な制御フローが必要な場合：
Fiber を採用し、コールバックの迷宮から脱却せよ。ただし、そのメモリコストとライフサイクル管理の重みを意識したアーキテクチャ設計が不可欠である。
Zend VMの挙動、メモリ配置、そしてオペコードの実行順序を脳内で完璧にトレースできる者だけが、PHPの限界を突破し、真に堅牢かつ超高速なWebシステムを構築できる。技術の表面的な記述に惑わされず、常にコンパイラとエンジンの鼓動を感じながらコードを紡ぎ出してほしい。