【テクニカル・上級編】Fiberのパフォーマンスチューニング：スタックサイズ、コンテキストスイッチ頻度、およびGCの影響 – PHPコア・内部エンジンと高速化・並行処理の極意解析バイブル

PHPコアの深淵：Fiberによる非同期並行処理の極限チューニングとZend VMのメモリ構造

PHPにおける非同期並行処理のパラダイムは、PHP 8.1で導入されたFiber（ファイバー）によってパラダイムシフトを迎えた。Node.jsやGo言語のゴルーチンに見るような、プリスクリプション（占有型）ではない、協調型（Cooperative）マルチタスキングの到来である。

しかし、この強力なプリミティブを使いこなすには、Zend VMのメモリ管理、コールスタックの割当戦略、そしてコンテキストスイッチの物理的コストを正確に把握していなければならない。ネット上に溢れる「 Fiberを使えば非同期になる」といった浅薄な解説を捨て、エンジン内部の挙動からパフォーマンスの限界を突破するための知見を紐解く。

—

1. Zend VMにおけるFiberの内部表現とメモリ空間

PHPの伝統的な実行モデルは、1リクエスト＝1プロセス（またはスレッド）の共有なき並行処理（Shared-nothing architecture）であり、コールスタックはOSのC言語スタック上に素直に構築されてきた。しかし、Fiberはこの常識を覆す。

実行コンテキスト（zend_execute_data）の分離

Zend VMにおいて、すべての関数呼び出しやメソッド実行は `zend_execute_data` 構造体の連結リストによって管理されている。通常、これらは単一の連続したコールスタック上で駆動する。

しかし、Fiberが生成されると、Zendエンジンは通常のコールスタックとは別に、独立したヒープ領域に独自のスタックと `zend_execute_data` の退避空間を確保する。これが `zend_fiber_context` である。

[通常のコールスタック (OS Stack)]
Global Scope -> Request Handler -> Fiber::suspend()
↓
[ヒープ上のFiberスタック]
zend_fiber_context

独自のエグゼキューションデータ
ローカル変数 / 変数テーブル (EG(symbol_table))

この分離により、Fiberのサスペンド（一時停止）とレジューム（再開）は、OSのコンテキストスイッチ（カーネルモードへの遷移を伴う重厚な処理）を一切発生させず、ユーザースペース内（Zend VM内）のポインタ書き換えのみで完結する。これが、プロセスやスレッドに比べてFiberのスイッチが圧倒的に高速である理由の本質だ。

—

2. スタックサイズのチューニングとメモリフットプリント

Fiberのインスタンスを生成する際、デフォルトでは一定のスタックサイズが割り当てられる。このスタックサイズの設定を誤ると、メモリの無駄遣い（Over-allocation）か、あるいは深刻なスタックオーバーフロー（Stack Overflow）を引き起こす。

デフォルトスタックサイズと変更の弊害

PHPのFiberは、Cレベルでメモリを確保する。膨大な数のFiber（例えば数万件の同時コネクション）を常駐させるアーキテクチャにおいて、デフォルトのスタックサイズ（プラットフォーム依存だが通常は数十KB〜1MB）をそのまま放置すれば、瞬く間にメモリが枯渇する。

start();
$fiber->resume(‘Resumed with payload’);

アーキテクチャ設計の指針

1. マイクロタスク用（スタック極小化）: 1つのFiberが単純なI/O待ちのプロキシとしてしか機能しない場合、コール深度は浅いため、スタックサイズを必要最小限にチューニングするべきである（C拡張側や将来的なコアの拡張を見据えた設計）。
2. 再帰・重度演算用: 再帰呼び出しやオブジェクトグラフが深い処理をFiber内で実行する場合、スタックオーバフローはCクラッシュ（Segmentation Fault）を誘発するため、安易な削減は禁物である。

—

3. コンテキストスイッチのオーバーヘッドとイベントループの統合

Fiber単体では、自律的にスケジューリングを行わない。必ず「イベントループ（Ev, Amp, ReactPHPなど）」と結合し、I/Oの完了をトリガーに `resume()` を叩く必要がある。

ここで発生するのが、コンテキストスイッチのオーバーヘッドである。

不要なスイッチの排除

Zend VMにとって、`Fiber::suspend()` と `Fiber::resume()` の往復は、opcodeのディスパッチループ内におけるわずかなポインタ操作とはいえ、PHPのスクリプト層から見れば無視できないコストになり得る。

以下のアンチパターンを避けよ：

細かすぎるタスク分割: 1行の処理ごとにFiberをサスペンド・レジュームさせるような設計は、VMのオーバーヘッドが実際のビジネスロジックの実行時間を凌駕する。
クロージャー生成の乱発: 毎回無名関数を生成してFiberに渡すと、Zendのシンボルテーブルとメモリマネージャー（ZMM）に負荷がかかる。

高速なイベントループ駆動の設計パターン

以下は、極限までコンテキストスイッチの無駄を削ぎ落とした、Fiberベースの非同期ワーカーの骨組みである。

/
private \SplQueue $queue;

public function __construct()
{
$this->queue = new \SplQueue();
}

public function spawn(callable $task): void
{
$fiber = new Fiber($task);
$this->queue->enqueue($fiber);
}

public function run(): void
{
while (!$this->queue->isEmpty()) {
$fiber = $this->queue->dequeue();

try {
if (!$fiber->isStarted()) {
$fiber->start();
} else {
// 前回サスペンドされた地点から再開
$fiber->resume();
}

// まだ終了していなければ、キューの末尾に戻す（協調型ラウンドロビン）
if (!$fiber->isTerminated()) {
$this->queue->enqueue($fiber);
}
} \Throwable $e) {
// 例外の伝播とログ出力
error_log(“Fiber terminated with exception: ” . $e->getMessage());
}
}
}
}

// 実行例
$engine = new AsyncEngine();

$engine->spawn(function () {
echo “Task 1: Start\n”;
Fiber::suspend(); // I/O待ちをシミュレート
echo “Task 1: Resume and finish\n”;
});

$engine->spawn(function () {
echo “Task 2: Start\n”;
Fiber::suspend(); // I/O待ちをシミュレート
echo “Task 2: Resume and finish\n”;
});

$engine->run();

—

4. ガベージコレクション（GC）とFiberのメモリリーク地獄

PHPのメモリ管理は参照カウント（Reference Counting）と、循環参照を回収するサイクルギャベージコレクタ（Cycle Collector）の二段構えで成り立っている。Fiberを導入したシステムで最も恐ろしいのは、「サスペンドされたFiberの中に保持されたローカル変数やオブジェクトが、意図せずメモリ上に残留し続ける」という現象である。

循環参照とサスペンド状態の罠

Fiberが `suspend()` によって停止している間、その実行コンテキスト（`zend_execute_data`）内に存在するすべてのローカル変数は生存し続ける。
もし、Fiber内のクロージャーやローカル変数が、外部の長期生存するオブジェクトやグローバルなコンテナと循環参照を形成した場合、そのFiberが終了（Terminated）するか明示的に破棄されるまで、一切のメモリが解放されない。

fiber = new Fiber(function () use ($context) {
$hugeData = str_repeat(‘A’, 1024 1024 10); // 10MBのペイロード

// ここでサスペンドすると、$context -> fiber -> クロージャー (use $context) -> $hugeData
// という強固な循環参照・参照チェーンが維持される
Fiber::suspend();

echo “Processing…\n”;
});

$context->fiber->start();

// $contextが生きている限り、Fiber内の $hugeData もGCの対象外となりメモリを圧迫し続ける

対策：明示的な参照の切断とライフサイクル管理

1. 巨大な変数のスコープ離脱: サスペンドする直前に、不要になった巨大な文字列や配列は `unset()` するか、変数のスコープから外す。
2. クロージャーの `use` 句の最適化: 必要最低限のプリミティブ型のみをキャプチャし、オブジェクトの参照を安易に持ち込まない。
3. 例外時の確実なクリーンアップ: Fiber内で例外が発生した場合やタスクが中断された場合、イベントループ側で確実にFiberインスタンスへの参照を断ち切り、参照カウントをゼロに落とす構造を担保する。

—

5. OPcacheプリローディングとの共存における注意点

本番環境のパフォーマンスを極限まで高めるため、OPcacheのプリローディング（Preloading）は必須である。クラス定義や関数が共有メモリ（SHM）にロードされ、リクエストごとのパース・コンパイルコストがゼロになる。

しかし、Fiberを多用するアーキテクチャでは、「プリロードされたクラスのメソッド内で動的に生成されるFiberと、無名関数のバインディング」に注意が必要だ。プリロードされたコードは全プロセス間で共有されるため、そこにプロセス固有の可変状態（Mutable State）を静的プロパティなどを通してFiber間で共有させると、競合状態（Race ConditionはPHPの単一スレッドモデルではないものの、リクエスト間やコルーチン間での汚染）や予期せぬ挙動の温床となる。

常に、Fiber内で処理されるデータはイミュータブル（不変）であるか、あるいはFiberのローカルスコープ内に完全にカプセル化されていることを保証しなければならない。

—

総括：PHPの限界を突破するアーキテクチャへ

Fiberは、ただの「コールバック地獄を回避するためのシンタックスシュガー」ではない。それはZend VMの内部構造に深く食い込み、PHPを真の意味での非同期・高スループットプラットフォームへと昇華させるための極限のツールである。

スタックサイズの厳密な管理、不必要なコンテキストスイッチの排除、そしてGCのメカニズムを熟知した者だけが、高負荷に耐えうる真のモダンPHP Webシステムを構築できる。フレームワークが隠蔽する抽象化のヴェールを剥ぎ取り、Zendエンジンと対話せよ。そこにあるのは、無限のパフォーマンスの領域だ。