こんにちは。普段から「どうすればPHPでよりスケーラブルな非同期I/Oを実現できるか」と頭を悩ませているあなたなら、PHP 8.1で導入されたFiber（ファイバー）の存在にすでに気付いていることでしょう。
Node.jsやGo言語、あるいはKotlinのコルーチンなどを触ってきた優秀なエンジニアほど、「PHPでもついにスタックレスな軽量スレッド（正確にはセミコルーチン）が使えるようになったぞ」と飛びつき、その強力な非同期の恩恵を実感したはずです。
しかし、ここで少し立ち止まってみてください。
「Fiberが中断（suspend）する瞬間、PHPの内部エンジン（Zend VM）ではいったい何が起きているのか？」
「なぜFiberを多用しすぎると、かえってパフォーマンスが落ちるケースがあるのか？」
今回は、ネット上のありふれた表面的な使い方ではなく、Zend VMの低レイヤの挙動、そして「Zendスタックのヒープ退避とメモリコピーコスト」という、一歩進んだエンジン内部の真実を一緒に紐解いていきましょう。ここを理解すると、あなたの書くPHPコードの「見えないコスト」が手にとるように綺麗に見えるようになりますよ。
—
1. そもそも「Zendスタック」とは何か？
私たちが普段書いているPHPの関数やメソッドは、実行されるときにC言語レベルのコールスタックではなく、Zendエンジンが管理する仮想的なスタック（Zend Execution Stack）上に積み上げられていきます。
PHPのプロセスは、リクエストを受け取ると、OSのメモリ空間上に巨大なプールの領域を確保します。その中で、関数呼び出しのたびに「スタックフレーム（`zend_execute_data`）」が次々とプッシュされ、returnするとポップされる。この一連の動きが、Zend VMの心臓部です。
[ 通常の関数コール時のZendスタックイメージ ]
———————————-
| main() の実行コンテキスト |
———————————-
| -> business_logic() |
———————————-
| -> fetch_data_from_db() | ← いまココ（ここにローカル変数やOPコードのポインタがある）
———————————-
通常の同期処理であれば、関数が終了すればフレームは一瞬で破棄され、メモリの再配置コストはほぼゼロです。Zend VMは非常にシンプルで、このスタック操作を高速に行うことだけに特化して最適化されてきました。
しかし、ここに「任意の場所で処理を一時停止し、後から再開できる」というFiberが持ち込まれた瞬間、事態は劇的に複雑化します。
—
2. Fiberが中断（suspend）する瞬間、裏で何が起きているのか？
Fiberの最大の魅力は、コールスタックの深く底にある非同期処理（例えばHTTPリクエストの待ち受けなど）の中からでも、親のコンテキストを汚さずに `Fiber::suspend()` を呼び出せる点です。
では、この `suspend()` が実行されたとき、Zend VMの内部では物理的にどのような処理が走っているのでしょうか？
ここが今日の核心です。
同期処理であれば、スタックフレームは上から順に消えていきますが、Fiberの中断時は「まだ完了していない途中のスタックフレーム群」を、そのまま保持し続けなければなりません。
しかし、Zend VMのメインスタックにそれらをそのまま残しておくと、次に別のリクエストや別のコードが走ったときにスタックが上書きされてしまいます。
そのため、Zendエンジンは以下の物理的なステップを踏みます。
1. スタックの切り出し: 現在Fiber上で展開されている `zend_execute_data` のチェイン（連なり）を特定する。
2. ヒープへのクローン（メモリコピー）: そのスタックフレーム群、およびそこに紐づくローカル変数（`zval`）や実行状態のポインタをごっそりとヒープ領域（Heap）へとコピーする。
3. コントロールの返却: 制御をFiberの呼び出し元（メインの実行コンテキスト）へと安全に戻す。
[ Fiber::suspend() 実行時のメモリ移動 ]
Zend VMのメインスタック ヒープ領域 (Heap)
+———————–+ +———————————–+
| メインのコンテキスト | | [Fiberオブジェクト内部] |
+———————–+ コピー | ・中断された zend_execute_data |
| (一時的にFiber退避) | ——-> | ・ローカル変数 (zval) のスナップショット|
+———————–+ +———————————–+
そう、お気づきでしょうか？
「スタックからヒープへの移動」とは、すなわち「メモリの動的アロケーション」と「バイトデータのコピー（memcpy的な処理）」を意味します。
—
3. このメモリコピーがもたらす「パフォーマンスの代償」
他の高水準言語（例えばGo言語のGoroutineなど）は、最初からヒープベースのスタック管理（あるいは可変長スタック）を前提として設計されていることが多いです。そのため、コンテキストスイッチの仕組みが言語コアのアーキテクチャに深く最適化されています。
一方、PHPは「1リクエスト＝リクエスト終端ですべてのメモリを一括解放（リクエストライフサイクル）」という強烈なシンプルさの上に成り立っています。この設計思想のおかげで、PHPはガベージコレクションのオーバーヘッドを最小限に抑え、爆速で動くことができます。
しかし、Fiberを使うということは、PHPの伝統的な「スタックベースの高速な実行モデル」の脇に、ヒープをまたぐ動的なコンテキストスイッチのコストを強制的に持ち込むことを意味します。
具体的な負荷の正体
- CPUキャッシュのミス（Cache Miss）: ヒープ上に散らばったメモリ領域を行き来するため、CPUのL1/L2キャッシュのヒット率が低下します。
- アロケータの負荷: `zend_string` や `zval` といった変数の塊をヒープ側にコピー・再構築するため、Zendメモリマネージャ（zend_mm）に追加の負荷がかかります。
浅いコールスタックで数回Fiberをスイッチする程度であれば、人間の知覚できない数マイクロ秒の世界です。しかし、数千件の並行処理をループの深部で行ったり、深いコールスタックを持つ複雑なフレームワークの内部で何層ものFiberスイッチを多発させたりすると、この「メモリコピーの累積」がじわじわとCPUを蝕み、期待したほどのパフォーマンスが出ないという壁にぶつかります。
—
4. アーキテクトとしてどう向き合うべきか？
「じゃあ、PHPのFiberは使わない方がいいのか？」
いいえ、そんなことはありません。技術の本質を知っていれば、恐れる必要は全くありません。要は適材適所です。
実戦における設計の指針
1. コールスタックを浅く保つ:
Fiber内で実行される処理のネスト（関数の深さ）をなるべく浅く設計してください。コピーする `zend_execute_data` の量が少なければ、ヒープへの退避コストは実質無視できるレベルになります。
2. I/Oバウンドな処理に絞る:
CPUバウンドな計算処理をFiberで細かく分割しても、コンテキストスイッチのオーバーヘッドで逆に遅くなります。データベースのクエリ待ち、外部APIの非同期コールなど、「待つ時間」が圧倒的に長いI/Oバウンドな領域にのみFiberを投入するのが定石です。
3. ライブラリの設計思想を見極める:
最近のモダンな非同期PHPライブラリ（ Revolt やAmp v3など）は、このエンジンの挙動を熟知した上で、無駄なスタック肥大化を防ぐ洗練されたAPIを提供しています。生のFiberを直接生焼けで乱用するのではなく、こうした枯れたエコシステムの上に乗るのが、プロのアーキテクトの選択です。
—
5. まとめ
今回は、Fiberのコンテキストスイッチの裏側にある「Zendスタックの退避とヒープコピー」という、一歩踏み込んだエンジン内部のメカニズムを解説しました。
- Fiberの中断時、Zendスタックのフレーム群はヒープ領域へメモリコピーされる。
- この仕組みは強力だが、PHP本来の「リクエスト完結型のシンプルなスタック処理」の枠外で行われるため、呼び出しが深すぎたり頻繁すぎたりするとパフォーマンス上のペナルティ（メモリ・CPUコスト）が発生する。
「なぜこのコードは少し重いのか？」
「なぜこの設計だとメモリ効率が悪くなるのか？」
その答えの多くは、今回見てきたようなZend VMのメモリ空間の動きに隠されています。この低レイヤの視点さえあれば、あなたが書くコードはただ動くだけでなく、エンジンに愛される美しく効率的なシステムへと生まれ変わります。
PHPの裏側は、知れば知るほど実にエキサイティングで美しい構造をしています。ぜひ、今日の知見を次の設計やコードレビューに活かしてみてくださいね。