Fiberのコンテキストスイッチにおける『Zend Stack』の退避とヒープへのコピーコスト
PHP 8.1における最大のパラダイムシフトは、間違いなく `Fiber`（ファイバー）の導入であった。これにより、コールスタックの途中で実行を一時停止し、任意のタイミングで再開するという「スタックフル・コルーチン」がPHPの言語空間にネイティブ実装された。
しかし、世の多くのプログラマブルな記事は、「非同期処理が簡単に書ける」「I/O待ちのブロッキングを回避できる」という表層的なメリットしか語らない。
アーキテクトたる者、その美辞麗句の裏でZend VMのメモリ空間がどのような物理的コストを支払っているのかを直視しなければならない。
Fiberのサスペンド（一時停止）時、Zend VMのコールスタック（Zend Stack）は、連続したCのコールスタック上からヒープ領域へと動的にコピーされる。このメモリコピーのメカニズム、そしてキャッシュミスの代償を正確に把握していなければ、並行処理を導入した瞬間にレイテンシが悪化するという本末転倒な事態を招く。
今回は、Zend VMの内部構造、スタックフレームの物理レイアウト、そしてFiberがコンテキストスイッチを引き起こす瞬間の低レイヤ挙動を極限まで解剖する。
—
1. Zend VMの実行モデルと「Zend Stack」の物理構造
PHPのコードは、lexerとparserによって抽象構文木（AST）に変換され、最終的にZend VMが実行する「オペコード（Opcode）」へとコンパイルされる。
Zend VMはスタックマシンベースではなく、レジスタマシンに近いハイブリッドな仮想マシンとして設計されている。
実行時、関数呼び出しやローカル変数の管理には `_zend_execute_data` という構造体が使われる。
これが俗に言う「Zend Stack（コールスタック）」を構成するノードである。
通常、同期的なPHPスクリプトの実行において、この `zend_execute_data` のチェーンは、C言語のネイティブコールスタック（OSのスレッドスタック）上に連続して積み上げられていく。CPUのキャッシュ（L1/L2）の局所性が極めて高く保たれるため、メモリ参照のオーバーヘッドは最小限に抑えられている。
しかし、Fiberはこの前提を破壊する。
—
2. Fiberサスペンド時における「Zend Stack」のヒープ退避
Fiberが内部で `Fiber::suspend()` を呼び出した瞬間、Zend VMは何を行っているのか。
Cのネイティブスタック上に展開されている `zend_execute_data` のチェーンは、そのままでは別のコンテキスト（例えばイベントループの別のタスク）に処理が移った際に上書きされてしまう、あるいは保持し続けることができない。
なぜなら、Cのスタックは単一の直線的なメモリ領域だからだ。
そのため、Fiberは以下の物理的処理を強制される。
1. カレントの実行コンテキストの凍結: 現在の `zend_execute_data` から、Fiberが占有するルートまでのスタックフレーム群を特定する。
2. ヒープ領域へのアロケーション: `emalloc()`（ZendMemory Manager経由）を呼び出し、スタックフレーム群を格納するための十分な連続したヒープメモリを確保する。
3. メモリのディープコピー: Cスタック上にある `zend_execute_data` 構造体、およびそれに紐づくローカル変数（`zval`）の配列を、ヒープ上の領域へ丸ごとコピーする。
4. ポインタの書き換え（Relocation）: コピーされたフレーム内の各種ポインタ（関数定義へのポインタ、thisコンテキスト、ローカル変数の参照など）がヒープ上の新しいアドレスを指すように、再計算・パッチ当てを行う。
この一連の処理は、C言語レベルの `memcpy` やポインタ演算を伴うため、CPUサイクルを確実に消費する。
/
// 重い処理を模したジェネレータ的Fiber
$fiber = new Fiber(function (int $seed): void {
$local_heavy_variable = range(1, 10000); // ヒープを圧迫するローカル変数
echo “Fiber: 実行開始 (Seed: {$seed})\n”;
// 最初のサスペンド：ここでZend Stackがヒープへコピーされる
$received = Fiber::suspend($local_heavy_variable[count($local_heavy_variable) – 1]);
echo “Fiber: 再開完了 (Received: {$received})\n”;
});
// — メインコンテキスト —
echo “Main: Fiberを起動\n”;
$value_out = $fiber->start(42);
echo “Main: Fiberから値を受取: {$value_out}\n”;
// レジューム：ヒープからZend StackがCスタックへ（あるいは一時的コンテキストへ）復元される
echo “Main: Fiberを再開\n”;
$fiber->resume(100);
上記のコードにおいて、`$local_heavy_variable` 自体はすでにPHPのヒープ上に確保されている `zend_array`（HashTable）であるが、それを指し示すローカル変数（シンボルテーブル上の `zval`）や、関数呼び出しのメタデータを含む `zend_execute_data` 自体が、サスペンド時に二重の意味でヒープとスタックの間を揺さぶられることになる。
—
3. ヒープアロケーションとメモリコピーのパフォーマンス負荷
「たかがメモリコピー」と侮ってはならない。
現代のCPUアーキテクチャにおいて、最大のボトルネックは演算器の速度ではなく「メモリレイテンシ」である。
Fiberのコンテキストスイッチ（Suspend / Resume）が発生するたびに以下のコストが顕在化する。
ZMM（Zend Memory Manager）のフラグメンテーション
Fiberがサスペンドするたびに `emalloc()` / `efree()` が高頻度で呼ばれると、Zendの独自メモリマネージャ（Heap）に断片化（Fragmentation）を引き起こす。
特に大量の並行Fiberを稼働させる場合、メモリプールのロック競合やページフォールトの確率が跳ね上がり、結果としてスループットが低下する。
キャッシュミスの急増
Cの連続したスタック上にあればL1/L2キャッシュにヒットしていたデータが、ヒープ上の散らばった領域にコピーされることで、TLB（Translation Lookaside Buffer）ミスやキャッシュミスが多発する。
非同期処理のメリット（I/O待ちの効率化）を、CPUキャッシュ効率の悪化（メモリスレートの増大）が相殺してしまうジレンマがここにある。
—
4. アーキテクトが知るべき実践的最適化指針
では、このZend VMの物理的制約を踏まえた上で、高スループットなPHPアプリケーションを設計するにはどうすればよいか。
1. 「浅いコールスタック」でFiberを運用する
Fiber内でさらに何段もの深さで関数呼び出しを行っている状態でサスペンドすると、コピーすべき `zend_execute_data` のチェーンが長くなり、コピーコストが直線的に増加する。
Fiberのエントリポイント（コールバック関数）の直下でビジネスロジックを完結させ、呼び出し深度（Call Depth）を浅く保つ設計が極めて有効である。
2. ループ内での過剰なサスペンドを避ける
例えば、数万件のレコードを処理する際に、1レコードごとに `Fiber::suspend()` を呼ぶような実装は、Zend VMのコンテキストスイッチオーバヘッドが本来の処理時間を容易に超越する。
バッチ処理（チャンク処理）を行い、コンテキストスイッチの頻度そのものを物理的に抑制すべきである。
3. OPcacheプリローディングとの関係性
OPcacheのプリロード（`opcache.preload`）によって関数やクラスの定義は永続メモリ（SHM: 共有メモリ）上に配置され、実行時のコンパイルコストは排除される。
しかし、実行時のローカル変数やスタックフレーム（`zend_execute_data`）は依然としてプロセスごとのプライベートメモリ上に動的構築されるため、Fiberのサスペンド/レジュームによるヒープコピーコスト自体は軽減されない。
この構造的限界を理解した上で、プロセスモデル（PHP-FPMのワーカー数やSwoole/RoadRunnerのような常駐型ランタイムのアーキテクチャ）との兼ね合いを設計する必要がある。
—
結言
PHPのFiberは魔法の弾丸ではない。それはZend VMの実行モデルの上に構築された、精巧かつ泥臭い「メモリの退避と復元のメカニズム」に他ならない。
低レイヤの構造――Zend Stackの物理的レイアウト、ZMMの挙動、そしてCPUキャッシュの局所性――を脳内に完全にトレースできた者だけが、真にスケーラブルで予測可能なパフォーマンスを持つWebシステムを構築できる。
フレームワークの機能リストを眺めるだけのエンジニアを卒業し、Zend VMの鼓動を感じながらコードを書け。それこそが、真のPHPアーキテクトの姿である。