PHPコアの深層：GeneratorとFiberのメモリ効率とコンテキストスイッチの物理的差異
Zend VMの内部構造において、処理の遅延評価（Lazy Evaluation）と協いマルチタスク（Cooperative Multitasking）を司る機構として、Generator（ジェネレータ）とFiber（ファイバー）が存在する。
多くのWebエンジニアは、これらを単なる「非同期処理のための便利な構文」程度に捉えているが、システムアーキテクトの視座から見れば、両者はメモリ空間の占有方式、Zend VMのコールスタックの保持方法、そしてCPUキャッシュのヒット率に至るまで、全く異なる物理的特性を持つ。
本稿では、Zend VMのソースコード（`Zend/zend_generators.c` および `Zend/zend_fibers.c`）の挙動をベースに、GeneratorとFiberがメモリ上でどのように振る舞うのか、その極限の差異を解き明かす。
—
1. Zend VMにおける実行コンテキストの基本構造
PHPの1リクエストは、単一のOSスレッド上で動くZend VMのメインインタプリターループによって実行される。関数呼び出しやメソッド実行が行われるたび、Zend VMはヒープ上に `zend_execute_data` 構造体を割り当て、これを連結リスト形式でスタックとして積み上げていく。
通常の関数呼び出しであれば、return時にこのスタックフレームは破棄されるが、実行途中で状態を保持したまま処理を中断（Suspend）し、外部へ制御を返す仕組みが必要な場合、スタックの寿命を延命させる必要がある。これがGeneratorとFiberの本質である。
—
2. Generatorの内部構造：軽量なステートマシーン
メモリ配置とHashTableの消費
GeneratorはPHP 5.5で導入されて以来、メモリ効率の良いイテレーションの代名詞として使われてきた。
内部的には、`Generator` オブジェクトは `zend_generator` 構造体としてヒープ上に生成される。
typedef struct _zend_generator {
zend_object std;
zend_function func;
zend_execute_data execute_data;
zend_execute_data stack;
// … 状態フラグや値のポインタ
} zend_generator;
Generatorの最大の特徴は、「自身の呼び出し元スタックフレーム（`zend_execute_data`）を丸ごとヒープ上に退避させる」点にある。
関数が `yield` に到達すると、Zend VMはその時点のローカル変数、オペコードの実行ポインタ（`opline`）、そして一時変数を保持したまま、一度インタプリタのメインループへと脱出（Return）する。
Generatorの物理的限界
Generatorは「スタック全体をコピー・保持するわけではない」。中断された関数フレームへのポインタ（参照）をオブジェクトが保持し続けるだけであるため、メモリ消費量は極めて小さい（O(1)の空間計算量）。
しかし、Generatorには致命的な構造的制約がある。それは「コールスタックの深さが1段に制限される（フラットである）」という点だ。
Generator内で別の関数を呼び出し、その奥深くで `yield` しようとしても、Zend VMのアーキテクチャ上、途中の通常関数が `zend_execute_data` をフラットに保持できないため、直接的なサスペンド＆レジュームは不可能である（これを解決するのがGenerator Delegation `yield from` であるが、これも内部的にはネストされたイテレータの委譲に過ぎない）。
—
3. Fiberの内部構造：スタックフル・コルーチンの重量級制御
PHP 8.1で導入されたFiberは、Generatorの制約を完全に打ち破るスタックフル・コルーチン（Stackful Coroutine）である。
独自のCスタック（Fiber Stack）の確保
Fiberは、PHPの関数実行コンテキストだけでなく、CPUの実行スタックそのもの（あるいはOS/サードパーティライブラリによるスタック領域）を動的に確保する。
Zend VMの `zend_fiber` 構造体は、以下のような要素を持つ。
- Fiber用メモリスタック: デフォルトでは通常数MB（または設定されたサイズ）の連続したメモリブロックをヒープ上に確保。
- 実行コンテキスト（Context）: CPUレジスタ（スタックポインタ、ベースポインタなど）の退避領域。
これにより、Fiber内部であれば、どれほど深く関数呼び出しがネストしていようとも、そのコールスタック全体を丸ごと凍結（Suspend）し、別のコンテキストへ切り替える（Switch）ことが可能になる。
Fiberのコンテキストスイッチのコスト
非常に強力なFiberだが、その代償は「メモリ消費量」と「キャッシュ効率」にある。
各Fiberは独自のスタック領域を持つため、数千〜数万のFiberを同時に起動すると、瞬く間にヒープメモリが圧迫される。また、コンテキストスイッチ時にはCPUレジスタの退避と復元が発生するため、純粋なCPUサイクル的にもGeneratorより重い。
—
4. 物理的差異の比較マトリクス
| 評価軸 | Generator (遅延評価イテレータ) | Fiber (スタックフル・コルーチン) |
| :— | :— | :— |
| スタック保持方式 | 単一の `zend_execute_data` のみ保持 | 独自のコールスタック全体をヒープ上に確保 |
| メモリフットプリント | 極小（数バイト〜数十KBのオブジェクトとフレーム） | 大（デフォルトで数MBのスタック領域を消費） |
| ネストした関数の中断 | 不可（`yield from` による委譲が必要） | 可能（任意の深さの関数から `Fiber::suspend()` 可能） |
| 主なユースケース | 大規模データセットの逐次処理、ストリーム処理 | 非同期I/O、タスクスケジューラ、並行処理フレームワーク |
—
5. 実践：Zend VMの挙動を意識したコード実装
以下のPHPコードは、メモリ効率の極限を意識したGeneratorによるストリーム処理と、Fiberによる協調型タスクランナーの骨組みである。
/
function streamLargeLog(string $filePath): \Generator {
$handle = fopen($filePath, ‘rb’);
if ($handle === false) {
throw new \RuntimeException(“Failed to open file.”);
}
try {
while (($line = fgets($handle)) !== false) {
// yieldによって制御権を呼び出し元へ返し、メモリを肥大化させない
yield trim($line);
}
} finally {
fclose($handle); // スコープを抜ける際に確実にあらゆるリソースを解放
}
}
// 実行時のメモリピークは極限まで抑えられる
// foreach ($streamLargeLog(‘/var/log/heavy.log’) as $logLine) {
// // 1行ずつの処理
// }
/
- 【事例2】Fiberによるタスクスイッチのシミュレーション
- 呼び出しの深さに依存せず、任意の地点でコンテキストを中断・再開する。
/
function runFiberPipeline(): void {
$fiber = new \Fiber(function (string $name): void {
echo “Fiber [{$name}] started.\n”;
// 深い関数呼び出しの最中であっても中断可能
$result = deepNestedTask(‘Payload Data’);
echo “Fiber [{$name}] resumed with: {$result}\n”;
});
// Fiberの開始
$fiber->start(‘Task-Alpha’);
echo “Main context working…\n”;
// Fiberへデータを渡して再開（Resume）
if (!$fiber->isTerminated()) {
$fiber->resume(‘Processed by Main’);
}
}
function deepNestedTask(string $data): string {
// 任意の深いコールスタック
$processed = “[” . strtoupper($data) . “]”;
// 処理の途中で中断し、メインコンテキストへ制御を戻す
$fromMain = \Fiber::suspend($processed);
return “Final: ” . $fromMain;
}
// 実行
// runFiberPipeline();
—
6. セキュリティとメモリ管理の罠：オブジェクトインジェクションとFiber/Generatorの交錯
極限の最適化を追求するアーキテクトが警鐘を鳴らすべき点として、これらの遅延評価機構や非同期機構が、セキュリティ脆弱性（特にPHPオブジェクトインジェクションからのGadget Chain構築）に与える影響がある。
シリアライズ時のリスク
`Generator` や `Fiber` オブジェクト、あるいはそれらが保持するクロージャ（Closure）や内部状態は、`serialize()` / `unserialize()` の対象外である場合が多い（あるいはシリアライズしようとすると例外が発生する）。しかし、オブジェクトインジェクションの脆弱性が存在し、攻撃者が悪意あるマジックメソッド（`__destruct` や `__wakeup`）を持つクラスをインjectedした場合、Zend VMのヒープ上にある未解放の `zend_execute_data` やリソースハンドルの破壊を引き起こす可能性がある。
特に、Fiberのスタック内に存在するオブジェクト参照が不適切なタイミングでガベージコレクション（GC）の対象となると、デストラクタの実行順序が狂い、予期せぬUAF（Use-After-Free）や型混乱（Type Juggling）を引き起こすアタックサーフェスになり得る。
高負荷な非同期・ストリーミング処理を実装する際は、メモリ効率の最適化だけでなく、コンテキストが保持するライフサイクル管理（スコープアウト時の確実なリソース破棄）を徹底しなければならない。
—
総括
PHPコアの内部構造において、Generatorは「メモリを消費しないイテレーションの極限」であり、Fiberは「複雑なコールスタックを維持したまま並行処理を行うための重量級機構」である。
アーキテクトは、単に「書きやすいから」「流行っているから」という理由でこれらを選択してはならない。扱うデータの規模、コールスタックの深さ、そして許容されるメモリフットプリントを物理的に計算し、Zend VMのエンジンが最も効率よくCPUキャッシュとメモリをヒットさせられる設計を選択することこそが、真にスケーラブルなWebシステムを構築する唯一の道である。