【実務・中級編】Zend VMにおけるスタックフレーム管理とFiberのメモリ消費：大規模並行処理におけるスタックオーバーフローの回避 – PHPコア・内部エンジンと高速化・並行処理の極意解析バイブル

Zend VMにおけるスタックフレーム管理とFiberのメモリ消費：大規模並行処理におけるスタックオーバーフローの回避

PHPでの非同期・並行処理といえば、かつては`ext-pcntl`を用いたマルチプロセス制御や、`ReactPHP` / `Amp`といったイベントループ駆動の非同期IOが主流であった。しかし、PHP 8.1で導入されたFiber（ファイバー）により、言語レベルの協調的マルチタスク（Cooperative Multitasking）がネイティブでサポートされ、コールバック地獄から解放された直感的な同期スタイルの非同期コード記述が可能となった。

一方で、フレームワークのレイヤーやI/Oバウンドなマイクロサービスにおいて、何万ものFiberを同時に生成・稼働させる設計を採用した場合、Zend VMのメモリ構造とスタックフレームの挙動を正しく理解していないと思わぬ「スタックオーバーフロー」や「ヒープ断片化」の罠に直面する。

本稿では、Zend VMのコールスタック管理の低レイヤな挙動を紐解き、大規模並行処理環境においてFiberを安全かつ高効率に運用するためのメモリ設計原則を解説する。

—

1. Zend VMのコールスタックと従来の限界

PHPの実行実体はCで書かれたZend Engineである。通常、PHPの関数呼び出しやメソッド実行は、OSのネイティブコールスタック（Cスタック）上ではなく、Zend VMがヒープ上に割り当てた独自の実行スタック（Execution Stack）上で展開される。

`_zend_execute_data` の構造

Zend VMにおいて、関数やメソッドの呼び出しコンテキストは `zend_execute_data` という構造体によって管理される。この構造体は以下の要素を保持している。

`opline`: 現在実行中のオペコード（Opcode）へのポインタ
`function`: 実行中の関数/メソッドの設計図（`zend_function`）
`symbol_table`: ローカル変数を格納するシンボルテーブル（高速な配列ルックアップを行うための `HashTable`）
`prev_execute_data`: 呼び出し元のスタックフレームへのポインタ（リンクリスト構造）

従来のPHPでは、コールツリーの深さはそのままこの `prev_execute_data` のリンクリストの長さに直結していた。無限再帰や過度なネストが発生した場合、Zend Engine自体に組み込まれたガード（`zend_vm_stack_extend` やメモリ制限）に達するまでフレームが積み上がり、最終的に `Allowed memory size of … bytes exhausted` またはセグメンテーション違反を引き起こしていた。

—

2. Fiberの正体：ヒープ上に退避される実行コンテキスト

Fiberが従来の関数呼び出しと決定的に異なる点は、「独自のコールスタック（`zend_vm_stack`）をヒープ上に独立して確保する」という点にある。

[従来のPHP実行フロー]
Global Scope ──> Function A ──> Function B ──> Function C (単一のZend VMスタック)

[Fiberを用いた実行フロー]
Global Scope
│
├─> Fiber #1 ──> [専用の zend_vm_stack (Heap)] ──> 吊り下げ(Suspend) / 再開(Resume)
└─> Fiber #2 ──> [別の zend_vm_stack (Heap)] ──> 吊り下げ(Suspend) / 再開(Resume)

Fiberが生成（`new Fiber(…)`）されるとき、Zend Engineはデフォルトで 256KB（プラットフォームやZendのビルド設定に依存）の仮想VMスタック領域をZendプロパーのメモリマネージャ（ZendMM）経由でヒープ上に確保する。

Fiber内で `Fiber::suspend()` が呼ばれると、現在の `zend_execute_data` のポインタ群の状態がFiberオブジェクト側にスナップショットとして退避され、コントロールフローは呼び出し元（メインの実行コンテキスト）へと即座に返還される。

このアーキテクチャが内包するリスク

1. メモリフットプリントの肥大化:
仮に10,000個のFiberを同時に起動した場合、純粋なスタック領域だけで $10,000 \times 256\text{KB} \approx 2.5\text{GB}$ のメモリがヒープ上に消費される。
2. スタックオーバーフローの変種:
Fiber自体のスタックサイズは固定（初期割り当て）であるため、Fiber内部で深すぎる再帰呼び出しや、巨大なローカル変数をスタックフレーム上に大量に展開した場合、OSのスタックではなくFiber専用のZend VMスタック領域が枯渇し、ハンドリング不能なクラッシュを引き起こす。

—

3. 実務で安全なFiber設計とコード実装

大規模なAPIクライアントの並行リクエストや、ワーカープロセスにおけるタスク並列処理を想定し、メモリリークやスタック枯渇を防ぐ堅牢な実装パターンを示す。

以下のコードは、数千件単位の外部HTTPリクエストを安全にチャンク分割（バッチ処理）し、メモリを定常状態に保ちながらFiberで並行処理する実用的なリファレンスである。

maxConcurrency = $maxConcurrency;
}

タスクをキューイングする
@param callable(): void $task

/
public function add(callable $task): void
{
$this->fibers[] = new Fiber(function () use ($task) {
try {
// Fiberのスコープ内でタスクを実行
$task();
} {
// try-finallyのクリーンアップ句（PHP 8..1+でサポートされた構文糖衣、あるいはfinally）
// Fiber終了時に確実にアクティブカウンターをデクリメントする
$this->activeCount–;
}
});
}

指定された同時実行数（Concurrency）を厳格に守りながら全Fiberを実行する

/
public function run(): void
{
$queue = &$this->fibers;

while (!empty($queue) || $this->activeCount > 0) {
// 同時実行数に余裕があり、かつキューにタスクが残っている間はFiberを起動
while ($this->activeCount < $this->maxConcurrency && !empty($queue)) {
/ @var Fiber $fiber /
$fiber = array_shift($queue);
$this->activeCount++;

try {
$fiber->start();
} catch (Throwable $e) {
// 予期せぬ例外の捕捉（ログ出力やエラーハンドリング）
error_log(sprintf(“[Fiber Error] %s in %s:%d”, $e->getMessage(), $e->getFile(), $e->getLine()));
}
}

// 非同期IOやイベントループの模擬：アクティブなFiberが処理を終える、
// あるいはsuspendされるのを待つためのマイクロ休止（ビジーウェイト回避）
// 実運用ではここにEventLoop（StreamSelect等）を統合する
usleep(1000);

// ライフサイクルが終了していないFiberの再開処理（必要に応じてループを回す）
foreach ($this->fibers as $fiber) {
if ($fiber->isSuspended()) {
try {
$fiber->resume();
} catch (Throwable $e) {
error_log(sprintf(“[Fiber Resume Error] %s”, $e->getMessage()));
}
}
}
}
}
}

// ==========================================
// 実行例：1000件のモックタスクを安全に並行処理
// ==========================================

require ‘vendor/autoload.php’;

$pool = new SafeFiberPool(maxConcurrency: 20); // 同時実行数を20に制限

for ($i = 1; $i <= 1000; $i++) { $taskId = $i; $pool->add(function () use ($taskId) {
echo “Task #{$taskId} started.\n”;

// 外部APIコールや重い処理をシミュレート
// 内部で Fiber::suspend() を呼ぶ非同期クライアントを想定
usleep(50000); // 50msのI/O待ちを模倣

echo “Task #{$taskId} finished.\n”;
});
}

$startTime = microtime(true);
$pool->run();
$endTime = microtime(true);

printf(“All tasks completed in %.2f seconds.\n”, $endTime – $startTime);

—

4. コードレビューの視点：なぜこの設計が必要なのか？

上記のコードおよび設計には、Zend VMのメモリ構造とGC（ガベージコレクション）のメカニズムに基づいた、明確なエンジニアリング上の意図がある。

① 無制限なFiber生成の禁止（背圧の制御）

「非同期だから全件一気に `new Fiber` を作って走らせれば早い」という安易な実装は、前述の通りZendMM上のヒープを瞬時に圧迫する。
`maxConcurrency`（同時実行数）をスライディングウィンドウ的に制限することで、Zend VMスタックが同時にメモリ上に展開される上限をハードコートし、OOM（Out of Memory）を物理的に防止する。

② クロージャ内の循環参照とメモリリークの排除

Fiberはそのライフサイクルが完了する（スコープを抜ける）まで、内部で使用されている変数の参照を保持し続ける。特に巨大なオブジェクトや配列を `use` 句でFiberのクロージャに持ち込むと、タスクが終了して制御が戻っても、ガベージコレクタが回収するまでの間メモリに居座り続ける。

> テクニカルリードからの教訓:
> 「Fiber内で使用するデータは、極力プリミティブ型に絞るか、IDやポインタのみを渡し、重いデータ構造は都度リポジトリ層やキャッシュ層から遅延ロード（Lazy Load）させよ。オブジェクトをFiberに丸ごと抱え込ませる設計は、ヒープ断片化の温床となる。」

③ 例外とスタックフレームのクリーンアップ

Fiber内部で未キャッチの例外が発生した場合、そのFiber専用のスタックフレームは破棄されるが、親コンテキストへ適切に伝播しないとサイレント失敗やリソースリーク（オープンされたソケットやDBコネクションの解放漏れ）につながる。
上記コードのように `try-finally` や確実なカウンタのデクリメントを保証する構造化を行わなければならない。

—

5. まとめ：PHPアーキテクトが守るべき鉄則

PHPにおけるFiberは、シングルスレッドでありながら強力なコンテキストスイッチをもたらす諸刃の剣である。これを網羅的かつ安全に使いこなすためには、以下の3点を心に刻むべきである。

1. スタックサイズは無限ではない: 1Fiberあたり数百KBのヒープが消費される現実を理解し、無制限な並行生成を行わない。
2. チャンク処理と並行数の制御（Concurrency Limiting）: リクエスト数に応じた適切なスロットリングを必ず実装する。
3. ライフサイクルとメモリの寿命を一致させる: 不要になったFiberやその内部変数は、速やかに参照を切断しZendMMへ返却するフローを構築する。

PHPはもはや「リクエストごとに全メモリを破棄するシンプルなスクリプト言語」の枠を超え、ロングランなプロセスや高度な非同期制御を行うエンタープライズ・ランタイムへと進化している。その低レイヤの構造を掌握した者だけが、真にスケーラブルで頑健なWebシステムを構築できる。