Fiberのコンテキストスイッチにおける「Zend Stack」の退避とヒープへのコピーコスト
PHP 8.1でのFiber（ファイバー）の導入は、PHPにおける非同期プログラミングのパラダイムシフトをもたらした。従来のC10K問題に対するブロッキングI/Oの呪縛を解き放ち、協調的マルチタスク（Cooperative Multitasking）をユーザーランドへ持ち込んだ立役者である。
しかし、コードレビューの場で「とりあえずFiberを使えば非同期になって速くなるんでしょ？」という安易な設計に遭遇するたび、私は冷や汗を禁じ得ない。Fiberは魔法の弾丸ではない。その裏では、Zend Engineの心臓部である「Zend Stack」の退避と、それに伴う容赦ないヒープメモリへのコピーコストが支払われているからだ。
今回は、Zend VMの内部構造からFiberのコンテキストスイッチの真実を暴き、メモリ効率を最大化するための設計原則を叩き込む。
—
1. Zend VMの物理構造：なぜFiberのスイッチは重いのか
PHPの実行モデルを語る上で避けて通れないのが 「Call Stack（呼出スタック）」 だ。通常の関数呼び出しにおいて、Zend VMはCPUのネイティブコールスタックとは別に、独自の仮想スタック（Zend Execution Stack）上に `_zend_execute_data` 構造体を積み上げていく。
このスタックは、関数ローカルの変数（Symbol Table）、引数、そして現在の実行ポインタ（OPline）の状態を保持するため、高速なL1/L2キャッシュに乗る連続したメモリ領域として極めて効率よく設計されている。
Fiber一時停止（Suspension）時の内部挙動
Fiberが `Fiber::suspend()` に到達した瞬間、Zend Engine内部では以下の物理的な事件が起きる。
1. スタックフレームの切り離し:
現在Fiber内で実行されている一連の `_zend_execute_data` チェーンを、現在の実行コンテキストから切り離す。
2. ヒープへのクローン（コピー）:
スタック上に存在していたフレーム群は、そのままではコールスタックの巻き戻し（Return）と共に破壊されるか、上書きされてしまう。そのため、Zend Engineはこれらを丸ごとヒープメモリ（Zend MM）上に動的確保したバッファへとコピー（退避）する。
3. VMの復帰:
制御権が呼び出し元（Fiberの外側）へ戻り、PHPのメイン実行ループはあたかも何事もなかったかのように別の処理を続行する。
この「スタックからヒープへのコピー」こそが、Fiberの最大のボトルネックである。
[通常実行時]
Zend Stack (高速・連続領域)
+———————–+
| execute_data (Fiber) |
+———————–+
| execute_data (Main) |
+———————–+
[Fiber::suspend() 実行時]
Zend Stack Zend Heap (EMALLOC)
+———————–+ (メモリコピー発生！)
| execute_data (Main) |–> [ 退避されたFiberのフレーム群 ]
+———————–+
スタックフレームの深さ（コール深度）が深ければ深いほど、あるいはローカル変数が保持するデータ量が大きければ大きいほど、このコピーコストは肥大化する。深い再帰呼び出しの最中でFiberをサスペンドさせる設計は、アーキテクチャ上の致命傷となり得るのだ。
—
2. 【アンチパターン】メモリをすり潰す「浅はかな非同期設計」
次のコードを見てほしい。一見すると、複数のI/Oタスクを並行処理する美しい非同期コードに見えるだろう。しかし、内部のZend VMの視点に立てば、これはメモリ効率の観点から最悪のアンチパターンだ。
/
function heavy_database_query_simulation(int $id): array {
// 局所的に巨大な配列を生成（ローカル変数がヒープ退避のコストを増大させる）
$heavyPayload = range(1, 10000);
// 意図的に深い関数呼び出しをシミュレート
return recursive_deep_processing($id, $heavyPayload);
}
function recursive_deep_processing(int $id, array $payload): array {
// サスペンド直前で巨大なスコープを維持したままフレームが深くなる
$result = array_map(fn($v) => $v $id, $payload);
// ここで強制的にサスペンド（Zend Stack -> Heapへの大量コピーが発生）
\Fiber::suspend(‘io_wait’);
return $result;
}
// メインの処理ループ
$fiber = new \Fiber(function() {
$data = heavy_database_query_simulation(42);
echo “Completed: ” . count($data) . “\n”;
});
// 起動とサスペンドの繰り返し（高頻度のコンテキストスイッチ）
$value = $fiber->start();
// … 何らかのI/O待ちを模倣 …
$fiber->resume();
なぜこのコードはレビューで即リジェクトされるのか？
1. 無駄なメモリ割り当てとコピー:
`heavy_database_query_simulation` 内の 10,000 要素の配列や中間変数が、`Fiber::suspend()` の瞬間にすべてヒープへコピーされる。これをリクエスト毎、あるいは数千回のループ内で高頻度に行うと、Zend Memory Manager (Zend MM) に甚大な断片化（Fragmentation）とALLOC/FREEのオーバーヘッドを引き起こす。
2. キャッシュミスの増大:
スタック上にあればCPUキャッシュの局所性（Locality of Reference）の恩恵を受けられたデータが、ヒープ上の散らばった領域に退避させられるため、CPUパイプライン効率が著しく低下する。
—
3. 実務で耐えうる堅牢な非同期設計：Zend VMの負荷を最小化する作法
では、PHPでFiberを実用的なレベルで安全に、かつ高パフォーマンスに扱うにはどうすればよいか。答えは「スコープの平坦化」と「データ最小化」である。
以下の要件を満たす設計を徹底せよ。
- Fiber内部のコールスタックを浅く保つ（Deep Call Stackの禁止）
- サスペンド境界を跨ぐスコープに巨大な変数を保持しない
- コンテキストスイッチの回数をビジネスロジックの要件に合わせて必要最小限にする
実用的なリファレンスコード例
以下は、非同期HTTPクライアントやワーカープールを想定した、メモリ効率に配慮したFiberハンドリングの模範実装である。
/
final class SafeFiberTask
{
private \Fiber $fiber;
private string $identifier;
private mixed $payload;
public function __construct(string $identifier, callable $task, mixed $payload = null)
{
$this->identifier = $identifier;
$this->payload = $payload;
// Fiberの初期化
// クロージャのスコープをクリーンに保ち、不要な外部変数のキャプチャ（use構文の乱用）を避ける
$this->fiber = new \Fiber(function () use ($task) {
try {
// タスクの実行と結果の返却
$result = $task($this->payload);
return [‘status’ => ‘fulfilled’, ‘data’ => $result];
} \Throwable $e {
return [‘status’ => ‘rejected’, ‘error’ => $e->getMessage()];
}
});
}
public function start(): mixed
{
return $this->fiber->start();
}
public function resume(mixed $value = null): mixed
{
return $this->fiber->resume($value);
}
public function isTerminated(): bool
{
return $this->fiber->isTerminated();
}
public function getIdentifier(): string
{
return $this->identifier;
}
}
/
- イベントループ（簡易的な協調的スケジューラ）
/
final class AsyncEventLoop
{
/ @var array
private array $tasks = [];
public function addTask(SafeFiberTask $task): void
{
$this->tasks[] = $task;
}
public function run(): void
{
// 全タスクが終了するまでラウンドロビンで実行
while (!empty($this->tasks)) {
foreach ($this->tasks as $index => $task) {
if ($task->isTerminated()) {
// 終了したタスクをプールから除去
unset($this->tasks[$index]);
continue;
}
// 初回起動または再開
if (!\Fiber::getCurrent()) {
// 初回はstart、以降はresume
// ※実際のフロー制御では状態に応じたハンドリングを行う
}
}
// 配列のインデックスを再構築
$this->tasks = array_values($this->tasks);
// CPUを不必要に焼き尽くさないための極小スリープ（またはepoll等の待受）
usleep(1000);
}
}
}
// ==========================================
// 実際の利用例（APIエンドポイントやバッチ処理）
// ==========================================
// メモリ効率を意識したタスク定義
$apiTask = function (array $context) {
// 1. 巨大なデータはサスペンド前に持たず、必要な最小限のID等だけを扱う
$userId = $context[‘user_id’];
// 2. 外部API呼び出し（モック）の前にサスペンド
// ここで退避されるexecute_dataのサイズは最小限に抑えられている
$suspendedReason = \Fiber::suspend(“Wait for HTTP API: user_{$userId}”);
// 3. レジューム後の処理
// 戻り値として受け取った外部リソースを処理する
return “Processed data for user {$userId} with response: ” . $suspendedReason;
};
// タスクの登録と実行制御
$taskRunner = new SafeFiberTask(‘task_001’, $apiTask, [‘user_id’ => 12345]);
$initialState = $taskRunner->start();
echo “Fiber Suspended with message: [{$initialState}] \n رم\n”;
// 外部I/O（cURLマルチなど）が完了したと仮定して、データを渡してレジューム
$finalResult = $taskRunner->resume(“HTTP_200_OK_PAYLOAD”);
print_r($finalResult);
—
4. チーフアーキテクトからの最終提言
PHPにおけるFiberは、Node.jsのAsync/AwaitやGoのGoroutineとは根本的に異なる。Goのゴルーチンスタックは動的に伸長・縮小し、かつ効率的なスケジューリング機構がランタイムに組み込まれているが、PHPのFiberはあくまで「Zend VMのスタックフレームをヒープに避難させる機構」に過ぎない。
したがって、以下の鉄則をチーム全体で共通認識として持たなければならない。
1. 「Fiberは速くするためのものではなく、I/O待ちのブロッキングを隠蔽し、コードの構造を美しく（同期的に）書くための抽象化である」という事実を忘れないこと。
2. フレームの深さとスコープ内の変数サイズに厳格なリミットを設けよ。 深い再帰や、数MBに及ぶオブジェクトグラフを保持したままのサスペンドは、OPcacheの最適化やJITコンパイルの効果をも相殺するメモリ帯域の無駄遣いを生む。
3. プロファイリングを怠るな。 `memory_get_usage(true)` や Blackfire などのプロファイラを用いて、Fiberのスイッチング頻度とメモリ割り当てのデルタを常に監視し、Zend MMが悲鳴を上げていないかを確認し続けること。
ハードウェアの物理法則（メモリバスの帯域、CPUキャッシュのヒット率）を無視したコードは、いかにモダンな構文を使っていようとも悪質なレガシーコードと同じだ。PHPの深層（Zend VM）の息吹を感じながら、美しく、かつ極限まで効率的な非同期アーキテクチャを構築してほしい。