こんにちは。PHPの裏側を覗く旅へようこそ。
普段、私たちはLaravelやSymfonyといったモダンなフレームワークを使い、何気なくコントローラーを書き、リクエストをさばいていますよね。PHP 8.1で導入された「Fiber（ファイバー）」によって、PHPでも本格的な非同期・協調的マルチタスク（Cooperative Multitasking）の扉が開かれました。
「Node.jsのasync/awaitやGoのgoroutineみたいなものだよね？」
そう思ってFiberを触り始めたエンジニアの多くが、ある壁にぶつかります。「一体、PHPのプロセス内部でコンテキストの切り替えはどう行われているのか？」、そして「なぜコールスタックの巻き戻りが起きないのか？」と。
今回は、Zend VMの内部構造とメモリ空間のレイアウトまで踏み込み、Fiberが実行コンテキストをどのように切り替えているのかを、低レイヤの視点から紐解いていきましょう。ここを理解すると、PHPという言語の美しさと、その実行モデルの全貌がクリアに見えてきますよ。
—
1. Zend VMの通常運転：スタックフレームの積み上げ
まず、Fiberが登場する前のPHPの基本、すなわち「通常の同期実行」がZend VM上でどう処理されているかを思い出してください。
PHPのコードは、パーサによってAST（抽象構文木）に変換され、最終的にZend VMが解釈・実行する「オペコード（Opcode）」へとコンパイルされます。このとき、関数呼び出しやメソッドの実行が発生するたびに、Zend VMはC言語のコールスタック（正確にはヒープ上に確保されたZendスタック）上に新しいスタックフレーム（`zend_execute_data`）を積み上げていきます。
[グローバルスコープ]
└─> functionA() 呼び出し
└─> `zend_execute_data` (フレームA)
└─> functionB() 呼び出し
└─> `zend_execute_data` (フレームB) ──> 現在の実行ポインタ (EX(opline))
この `zend_execute_data` には、ローカル変数、引数、実行中のオペコードの位置（`opline`）、そして「呼び出し元（caller）へのポインタ」がすべて含まれています。
通常のPHPでは、関数が値を返して終了する（`RETURN` オペコード）と、このスタックフレームが破棄され、呼び出し元のフレームへポインタが戻ります。これは一本道の「プリエンプティブ（またはシンプルなコール・リターン）」な世界です。
—
2. Fiberの正体：Zend VMスタックの「分離と退避」
では、Fiberを導入すると何が起きるでしょうか。
Fiberの本質は、「Zend VMの実行コンテキスト（スタックフレームのチェーン全体）を、丸ごとヒープ上に退避させ、別の実行コンテキストにすげ替える仕組み」です。
Go言語のgoroutineは、OSスレッドや独自のランタイムスケジューラによってプリエンプティブ（強制割り込み）に切り替えられますが、PHPのFiberは協調的（Cooperative）です。つまり、Fiber自身が明示的に `Fiber::suspend()` を呼び出さない限り、処理の制御権は移譲されません。
物理的なメモリ上で何が起きているかというと、次のような構造になっています。
1. メインの実行スタックとは別に、Fiberごとに独立したスタック領域がヒープ上に割り当てられます。
2. `Fiber::suspend()` が実行されると、Zend VMは現在の `zend_execute_data` のチェーンの先端をFiberオブジェクトの内部構造体に保存します。
3. コントロールは呼び出し元（Fiberを起動した側、あるいはイベントループ）へと一瞬で戻ります。
4. 再び `Fiber::resume()` が呼ばれると、保存されていた `zend_execute_data` のチェーンが復元され、サスペンドしたその瞬間（正確にはその次のオペコード）から実行が再開されます。
このメカニズムにより、「呼び出し元へ戻る（return）」のではなく、「途中の状態で一旦タイムカプセルに閉じ込めて、別の場所へ飛ぶ（yield/suspend）」ことが可能になるのです。
—
3. 実践：Fiberのライフサイクルとスタックの往復運動
百聞は一見にしかず。ごくシンプルなFiberのコードを通じて、このスタックの往復運動を脳内トレースしてみましょう。
start(‘PHP Architect’);
echo “[メイン] Fiberから受け取った値: ‘{$valueFromFiber}’\n”;
echo “[メイン] Fiberに値を送り込んで再開させます\n”;
// 3. Fiberを再開（値を内部へ渡す）
$secondValue = $fiber->resume(‘こんにちは、ファイバー！’);
echo “[メイン] Fiberから受け取った2回目の値: ‘{$secondValue}’\n”;
// 4. 再度ファイバーを再開して完結させる
$fiber->resume(‘最後のデータ’);
echo “[メイン] すべての処理が終了しました。\n”;
実行結果のトレース
このスクリプトを動かすと、出力は次のようになります。
[メイン] Fiberを起動します
[Fiber] 処理開始: PHP Architect
[メイン] Fiberから受け取った値: ‘一時停止します’
[メイン] Fiberに値を送り込んで再開させます
[Fiber] 再開されました。受け取った値: こんにちは、ファイバー！
[メイン] Fiberから受け取った2回目の値: ‘2回目の停止’
[Fiber] 処理完了
[メイン] すべての処理が終了しました。
見事にメインルーチンとFiberの内部を行ったり来たりしていますよね。
この裏側では、`$fiber->start()` や `$fiber->resume()`、そして `Fiber::suspend()` が実行されるたびに、Zend VMの `EG(current_execute_data)`（現在実行中のエクスクュートデータへのポインタ）が切り替わり、スタックフレームのポインタがダイナミックに変更されているのです。
—
4. アーキテクトの視点：なぜFiberを使うのか、どこに注意すべきか
「スタックが切り替わる仕組みは分かった。で、実際のWeb開発でどう活きるんだい？」という声が聞こえてきそうですね。
従来のPHP（特に伝統的なFPM環境）では、1つのリクエストに対して1つのプロセス（またはスレッド）が割り当てられ、データベースの応答や外部APIのHTTPリクエストを待っている間、そのプロセスは「ただ待つ（Blocked）」ことしかできませんでした。
しかし、Fiberをベースにしたイベントループ（AmpやReactPHPなどのエコシステム）を組み合わせると、次のようなパラダイムシフトが起きます。
1. I/O待ちの効率化: 外部APIへのリクエストを飛ばした瞬間に `Fiber::suspend()` し、その間に別のHTTPリクエストの処理（別のFiber）を進める。
2. メモリの節約: OSスレッドを何千個も立てるのではなく、軽量なZend VMのFiberコンテキスト（数百キロバイト程度）を切り替えるだけで、非同期多重化を実現できる。
ただし、最大の「落とし穴」を忘れてはいけません
Zend VMのスタックはFiberごとに分離されますが、グローバルステートやサードパーティのC拡張（PDOやMySQLiなどのレガシーなドライバ、各種Zend拡張）は、必ずしもFiberセーフ（再入可能：Reentrant）とは限りません。
例えば、あるFiberの途中でDB接続（PDOインスタンス）を保持したままサスペンドし、別のFiberが同じ接続を使ってクエリを投げた場合、ドライバ内部の通信パケットやステートがぐちゃぐちゃになり、予期せぬバグを引き起こす原因になります。
そのため、Fiberを活用する際は、非同期に対応した専用のドライバやクライアント（AmpやSwoole/OpenSwooleの非同期クライアントなど）を使用することが鉄則です。
—
まとめ
今回は、PHP 8.xのFiberにおけるZend VMの実行スタックとFiberスタックの物理的な共存メカニズムについて解説しました。
- Zend VMは、通常コールスタック（`zend_execute_data`）を積み上げて実行する。
- Fiberは、その実行コンテキスト（スタックフレームのチェーン）を丸ごとヒープ上に退避・復元する仕組みを持つ。
- `Fiber::suspend()` と `resume()` により、協調的なコンテキストスイッチが実現されている。
PHPは単なる「Webのテンプレート言語」から、こうした低レイヤのメモリ管理や実行モデルを内包した、極めて洗練されたモダンな言語へと進化を遂げています。
裏側の仕組みが見えると、コードを書くときの「メモリの動き」や「実行コスト」が手に取るようにイメージできるようになります。ぜひ、ご自身のアプリケーションのボトルネック解消や、イベントループ駆動のアーキテクチャ設計に、この知見を役立ててみてくださいね。