Zend VMのスタックフレーム管理とFiberのメモリ消費：大規模並行処理におけるスタックオーバーフローの回避
PHP 8.1で導入された `Fiber`（ファイバー）は、IOバウンドなタスクにおける非同期プロセスのパラダイムを劇的に変えた。コールバック地獄に陥りがちな従来のPromisesやReactPHP的アプローチに対し、同期的なコード記述スタイルを維持したまま協的中断（Cooperative Multitasking）を実現できるこの機能は、APIの並行処理やマイクロサービス間の通信において強力な武器となる。
しかし、コードレビューの現場において、Fiberを「魔法の非同期スレッド」と勘違いし、その内部メモリ構造への理解を欠いたまま実装された設計に遭遇することは少なくない。OSスレッドとは異なり、FiberはZend Engineのヒープ上に独自のコールスタックを持つ。ここに深い再帰呼び出しや肥大化したローカル変数が絡んだ瞬間、システムは予期せぬスタックオーバーフローやメモリ枯渇の闇に呑み込まれる。
今回は、Zend VMのスタックフレーム管理の低レイヤ挙動からFiberのメモリ消費モデルを解剖し、大規模並行処理を安全に捌くための設計ルールを伝授する。
—
1. Zend VMのスタックフレームとFiberの物理メモリ配置
传统的なコールスタックとZend VMの宿命
通常のPHPスクリプトの実行において、関数やメソッドの呼び出しは、CPUのハードウェアスタックではなく、Zend VMが管理する「実行スタック（Execution Stack）」上で展開される。このスタックは、`zend_execute_data` 構造体の連結リストとしてヒープ上にアロケートされ、ローカル変数、引数、一時変数（EX(Ts)）、そしてオペコードの実行ポインタ（opline）を保持している。
通常の同期処理であれば、関数がリターンするたびに `zend_execute_data` はポップされ、メモリは即座に解放されるため、コールスタックの深さは通常の再帰制限（`zend.max_execution_time` ではなく、CスタックやZendスタックの保護）に依存する。
Fiber導入による「スタックの独立」とヒープ消費
Fiberは、このZend VMの実行コンテキスト（`zend_execute_data` のチェーン、プレースホルダ、Fiber独自のコールスタック）を独立したヒープ領域に切り出す。
[ PHPプロセス (Zend Engine) ]
├── メイン実行コンテキスト (Main Execution Stack)
│ └── zend_execute_data (Global / Request Scope)
└── Fiberインスタンス空間 (Heap Allocated)
├── zend_fiber 構造体
└── 独自ヒープバッファ (Fiber Stack: デフォルト約1MBなど調整可能)
└── 孤立した zend_execute_data チェーン
ここで重要なのは、Fiberのスタック領域はOSのスレッドスタックのように無限に自動拡張（Guard Pageによる例外的な拡張を除く）するわけではなく、生成時に固定のサイズ（または動的チャンク）が割り当てられるという点だ。
大量のFiberを同時並行（数万〜数十万）で起動する設計をとった場合、1つのFiberあたりのメモリ消費がわずか数キロバイトであっても、総量として数ギガバイトのヒープを消費し、最終的にZendのメモリマネージャ（ZMM）の限界を超えて `Allowed memory size exhausted` あるいは致命的なセグメンテーション違反を引き起こす。
—
2. 実務における危険なアンチパターン：Fiber内での「深すぎる再帰」
以下のコードを見てほしい。一見すると美しく、非同期で木構造を走査しているように見えるが、Zend VMのメモリ構造を知る者からすれば悪夢のような実装だ。
/
function processNodeAsync(array $node): Fiber
{
return new Fiber(function () use ($node) {
// ローカル変数に巨大なデータを保持
$buffer = str_repeat(‘X’, 1024 64); // 64KBのペイロード
if (isset($node[‘children’])) {
foreach ($node[‘children’] as $child) {
// 再帰的にFiberを生成、またはネスト呼び出し
$subFiber = processNodeAsync($child);
$subFiber->start();
// 子の完了を待機 (サスペンド/レジュームの嵐)
while (!$subFiber->isTerminated()) {
Fiber::suspend();
$subFiber->resume();
}
}
}
return $node[‘id’] ?? null;
});
}
なぜこのコードは破綻するのか？
1. フレームの肥大化: `processNodeAsync` 内の `$buffer` や各変数は、Fiberがサスペンド（中断）している間もずっとヒープ上のFiberスタックに保持され続ける。
2. スタックの爆発: 再帰呼び出しのたびに新しい `zend_execute_data` とFiberコンテキストが生成され、ツリーの深さ（Depth）に比例してメモリが線形（あるいは指数関数的）に消費される。
3. VMのコンテキストスイッチコスト: Fiberのサスペンドとレジュームは軽量だが、頻繁なジャンプとポインタの書き換えはZend VMに重いオーバーヘッドを強いる。
—
3. 実践：メモリ効率と安全性を極限まで高めた堅牢なFiberタスクランナー
大規模なAPIリクエストの並行処理や、非同期のバッチ処理において、メモリリークやスタックオーバーフローを完全に回避するための「プロダクションレディなタスクプール・パターン」を提示する。
この実装では、以下の設計ルールを徹底している。
- スタックのフラット化（非再帰化）: 再帰を使わず、キュー（Queue）構造を用いたイテレーティブな処理により、Zend VMのスタックフレーム深度を常に一定に保つ。
- メモリプールの概念: 同時実行数（Concurrency Limit）を厳格に制御し、アクティブなFiberの数を制限する。
/
final class SafeFiberPool
{
/ @var array
private array $queue = [];
/ @var int 同時実行数の上限 /
private int $concurrencyLimit;
/ @var int 現在アクティブなFiber数 /
private int $activeCount = 0;
public function __construct(int $concurrencyLimit = 100)
{
$this->concurrencyLimit = max(1, $concurrencyLimit);
}
/
- タスクをキューにエンキューする
/
public function add(callable $task): void
{
$this->queue[] = $task;
}
/
- すべてのタスクを協調的に並行実行する
/
public function run(): void
{
$activeFibers = [];
while (!empty($this->queue) || !empty($activeFibers)) {
// 同時実行枠に空きがあり、キューにタスクがあればFiberを生成して起動
while ($this->activeCount < $this->concurrencyLimit && !empty($this->queue)) {
$task = array_shift($this->queue);
$fiber = new Fiber(function () use ($task) {
try {
// タスクを実行（内部で深い再帰を行わないフラットな設計を前提とする）
return $task();
} catch (Throwable $e) {
// エラーハンドリング：例外がFiber内で未捕捉の場合のリークを防ぐ
error_log(“Fiber Exception: ” . $e->getMessage());
return null;
}
});
$fiber->start();
if (!$fiber->isTerminated()) {
$activeFibers[] = $fiber;
$this->activeCount++;
}
}
// アクティブなFiberを順番にイテレート（ラウンドロビン方式の協調動作）
foreach ($activeFibers as $index => $fiber) {
if ($fiber->isSuspended()) {
try {
// 処理を再開
$fiber->resume();
} catch (Throwable $e) {
error_log(“Fiber Resume Exception: ” . $e->getMessage());
}
}
// 終了したFiberをプールからパージし、メモリを解放する
if ($fiber->isTerminated()) {
unset($activeFibers[$index]);
$this->activeCount–;
}
}
// CPUのスパイクを防ぐための微小なウェイト（必要に応じてUSleepやイベントループ連携）
if (!empty($activeFibers)) {
// 実運用ではEvent Loop (Amp / ReactPHP) や stream_select と統合すべきだが、
// 純粋なZend VM環境ではビジークイーンの負荷を下げるために挟む
usleep(1000);
}
// インデックスの再整理
$activeFibers = array_values($activeFibers);
}
}
}
// ==========================================
// 使用例（実務でのAPI並行フェッチを想定）
// ==========================================
$pool = new SafeFiberPool(concurrencyLimit: 10);
for ($i = 1; $i <= 50; $i++) {
$taskId = $i;
$pool->add(function () use ($taskId) {
echo “タスク #{$taskId} 開始\n”;
// 疑似的なIO待ち（実務では非同期HTTPクライアントのsuspendを利用）
Fiber::suspend();
echo “タスク #{$taskId} 終了\n”;
return “Result_{$taskId}”;
});
}
// 実行
$pool->run();
—
4. コードレビューの視点：アーキテクトからの厳格な設計ルール
プロジェクトのテクニカルリードとして、チームメンバーがFiberやZend VMの挙動を無視したコードをマージしないために、以下のチェックリストをコードレビューの絶対基準として課してほしい。
1. Fiber内での再帰呼び出しの禁止（No Deep Recursion in Fibers）
- ツリー構造やグラフ構造の走査をFiber内で行う場合は、再帰関数（Recursive Function）ではなく、明示的なスタック配列（LIFO構造）を使ったループ処理に書き換えること。これにより、Zend VMの `zend_execute_data` の肥大化を完全に防ぐ。
2. メモリフットプリントの計測と上限の設定
- 大規模な並行処理を実装する際は、`memory_get_usage(true)` を用いて、Fiberの数に対するメモリ線形増加の傾向をベンチマークで必ず確認する。特に、Fiberのクロージャ内に不要な巨大変数を `use` 句でキャプチャしていないか（クロージャのスコープ汚染）を厳しく査読する。
3. サスペンドポイントの管理
- Fiberのサスペンド（`Fiber::suspend()`）が無秩序に点在すると、コールスタックの状態追跡が極めて困難になり、デバッグ時のメンテナンシビリティが著しく低下する。IO待ちや外部API呼び出しなど、明確な非同期境界でのみサスペンドを行うアーキテクチャに統一すること。
PHPはもはや「単なるリクエスト毎に破棄されるスクリプト言語」ではない。Zend VMのメモリ管理構造とコンテキストのライフサイクルを完全に掌握した者だけが、モダンで堅牢な高スループットシステムを構築できる。メモリの重みを感じ取れ。コードの1行、1つの変数アロケーションが、ハードウェアのリソースと直結していることを忘れてはならない。