PHPコアの深層：Fiberコンテキストスイッチと `zend_fiber_context` の低レイヤ解析
PHPは長い間、共有ード・ノード・シェアード（Shared-nothing）アーキテクチャとプロセス/スレッド単位のリクエストライフサイクルを基本として発展してきた。C10K問題に代表される並行処理の壁に対し、従来はSwooleやRoadRunnerといった拡張モジュール、あるいはReactPHPなどのイベントループ駆動型ライブラリがその解となっていた。
しかし、PHP 8.1で導入された Fiber（ファイバー） は、ユーザーランドのコードに対して協調的マルチタスク（Cooperative Multitasking）のプリミティブをもたらし、スタックフルな非同期処理を言語コアレベルで完結させた。
本稿では、Fiberの抽象化されたAPIの向こう側――Zend VMがどのようにCPUレジスタを操作し、コールスタックを退避・復元しているのか。その核心である `zend_fiber_context` 構造体とコンテキストスイッチのメカニズムを、C言語レベルのZendエンジン内部構造から徹底的に解剖する。
—
1. 協調的マルチタスクの裏側：スタックレス vs スタックフル
非同期処理における最大の論点は「どこに実行状態（State）を保持するか」である。
- Generator（スタックレスコルーチン）:
内部的に `zend_generator` 構造体を持ち、ローカル変数の状態はヒープ上に退避される。しかし、関数呼び出しのネスト（コールツリー）を跨いだサスペンドは不可能である。
- Fiber（スタックフルコルーチン）:
実行ごとに独自のCコールスタック（メモリ空間）を確保する。これにより、どれほど深い関数の呼び出しツリーの内部であっても、任意の地点で一瞬にして実行を中断（Suspend）し、後から再開（Resume）することができる。
この「独自のCコールスタックの切り替え」を実現するために、ZendエンジンはOSのスレッド機構に頼らず、ユーザー空間でCPUレジスタとスタックポインタを直接操作する機構を持っている。それが Boost.Context のアセンブリベースの実装、あるいはPHP 8.1以降で導入された専用のファイバーAPI（`zend_fiber.c`）である。
—
2. `zend_fiber_context` 構造体の低レイヤ解剖
PHPのFiberの実体は、Zendエンジン内部における `zend_fiber` 構造体、そしてそれを支える低レイヤのコンテキスト管理構造体 `zend_fiber_context` である。
Zendソースコード（`Zend/zend_fibers.h`）を覗くと、この構造体はプラットフォーム依存のコンテキスト情報（ポインタ、スタックのベースアドレス、サイズ、そしてCPUレジスタの退避先）を保持していることがわかる。
/ Zend/zend_fibers.h の概念的・構造的理解のための定義抜粋 /
typedef struct _zend_fiber_context {
/ コンテキストの実行状態（未開始、実行中、サスペンド、終了） /
zend_fiber_status status;
/ 低レイヤのコンテキスト制御体（OS依存・Boost.Context等に類似した機構） /
void handle;
/ このファイバー専用に割り当てられたCコールスタックの底とサイズ /
void stack;
size_t stack_size;
/ ファイバーが中断された際のインストラクションポインタやスタックポインタの退避先 /
// 実際にはプラットフォームごとのレジスタ退避構造体が内包される
} zend_fiber_context;
コンテキストスイッチの本質：CPUレジスタの退避と復元
CPUが実行コンテキストを切り替えるとき、何が行われているのか。
x86_64アーキテクチャを例に取ると、CPUの挙動の本質は以下のレジスタ群の退避（Save）とロード（Restore）に集約される。
1. RIP (Instruction Pointer): 次に実行すべき機械語命令のアドレス
2. RSP (Stack Pointer): 現在のコールスタックのトップを指すアドレス
3. RBP (Base Pointer): スタックフレームの基準アドレス
4. Callee-saved Registers (RBX, R12, R13, R14, R15): 呼び出し側が値を保持し続けるべきレジスタ群
Fiberが `Fiber::suspend()` を呼び出した瞬間、Zend VMは現在のZendエクゼクティブ・ステート（実行中のOPコード位置、シンボルテーブルスコープ等）を保存すると同時に、CPUのハードウェアレベルのレジスタ（RSP, RIPなど）を `zend_fiber_context` が指す専用スタック領域へ退避させる。
そして、あらかじめ用意されていた別のファイバーの `zend_fiber_context` からレジスタ群をCPUにロードし直すことで、メモリ空間のジャンプを完了させるのだ。
—
3. 実践：PHP 8.1+ Fiberによる非同期I/Oの模擬とメモリの挙動
言葉だけでは抽象的なので、Zend VM上でFiberがどのように協調動作を行うのか、ユーザーランドのコードを通じてそのライフサイクルを脳内トレースしてみよう。
/
// 1. メインスレッド（グローバル・エクゼクティブ・スコープ）上でFiberを生成
$fiber = new Fiber(function (string $name): void {
echo “[Fiber] {$name}: 開始\n”;
// 2. 独自のスタックコンテキスト内で処理を中断し、親（メイン）へデータを渡す
$received = Fiber::suspend(“データ要求: 第一段階完了”);
echo “[Fiber] {$name}: 再開されました。受け取った値 -> {$received}\n”;
// 3. 処理の終了
Fiber::suspend(“データ要求: 第二段階完了”);
echo “[Fiber] {$name}: 終了\n”;
});
echo “[Main] ファイバー起動前\n”;
// 4. ファイバーをスタート（ここでCPU実行権がFiberのコールスタックへ移譲される）
$output1 = $fiber->start(“Worker-01”);
echo “[Main] ファイバーからサスペンドされた値: ‘{$output1}’\n”;
echo “[Main] メイン処理の合間…\n”;
// 5. 再びファイバーに実行権を戻しつつ、データを注入する
$output2 = $fiber->resume(“メインからのフィードバックA”);
echo “[Main] ファイバーから再びサスペンドされた値: ‘{$output2}’\n”;
// 6. ファイバーを完全に終了させる
$fiber->resume(“メインからのフィードバックB”);
echo “[Main] すべての処理が完了しました。\n”;
このコードがZend VM上で通る際の裏側の動き
1. `new Fiber(…)`: この時点ではCコールスタックは確保されず、PHPオブジェクトとしてのメタデータ（`zend_object` 内のハンドラ）が初期化されるのみ。
2. `$fiber->start()`: ここで初めて `zend_fiber_context` が初期化され、専用のメモリ領域（Cスタック）がアロケートされる。メインの実行コンテキスト（Caller）のレジスタが退避され、Fiber側（Callee）のレジスタとスタックポインタ（RSP）がロードされる。
3. `Fiber::suspend()`: 逆方向のコンテキストスイッチ。Fiberのスタック上で動いていたCPUレジスタが退避され、メイン側のスタックポインタとインストラクションポインタが復元される。これにより、呼び出し元であるメインスクリプトの次の行へシームレスに処理が戻る。
—
4. アーキテクチャ上の注意点と限界：FPMモデルとの親和性
ここで、PHPアーキテクトとして冷静に評価しなければならない現実がある。それは 「PHP-FPMモデルとFiberの本質的なミスマッチ」 である。
PHP-FPM（FastCGI Process Manager）は、1リクエスト＝1プロセス（またはスレッドプール）を基本としており、リクエスト終了時にはプロセスが保持していたすべてのメモリ（ZendMM）がOSによって一括解放される。
Fiberは同一リクエストの単一プロセス内でのみ並行処理（非同期ブロッキングI/Oの隠蔽）を実現するものであり、Node.jsやGo言語のような「ロングラン・プロセスで何万ものリクエストをイベントループでさばく」ためのものではない。
OPcacheとFiberの物理構造への影響
OPcacheプリローディング（`opcache.preload`）によって共有メモリ（SHM）上にバイトコード（OPコード）が配置される。Fiberの内部で実行される関数も、このプリロードされた共有メモリ上のOPコード配列を参照する。
つまり、複数のFiberが同時に異なるコンテキスト（ローカル変数テーブル、スタックフレーム）を持ちながら、同一の関数OPコードを安全に共有・実行できるのは、各Fiberが完全に独立した `zend_execute_data` とCコールスタックを持っているからに他ならない。
—
5. セキュリティ・ハックの文脈：ファイバー境界を跨ぐ脆弱性リスク
低レイヤのメモリ管理に踏み込むとき、セキュリティ上の懸念を見過ごすことはできない。特にPHPオブジェクトインジェクション（Object Injection）やガジェットチェーン（Gadget Chain）の文脈において、Fiberの存在はどのように影響するのか。
従来、脆弱性によって任意のクラスのデストラクタ（`__destruct()`）やマジックメソッド（`__wakeup()`）が意図せず実行される問題（オブジェクトインジェクション）は、単一のコールスタック上でシーケンシャルに発生していた。
しかし、Fiberコンテキストが導入されたシステムにおいて、悪意あるペイロードがFiberのライフサイクル（未開始、サスペンド中）に介入した場合、以下のような高度な攻撃ベクトルが成立する余地が生まれる。
- サスペンド状態のオブジェクトのゾンビ化:
Fiberがサスペンドした状態で保持されているローカル変数やスコープ内のオブジェクトは、ガベージコレクション（GC）のルートから一時的に外れる、あるいはライフサイクルが引き延ばされる。これにより、意図しないタイミングでのデストラクタ実行や、ステートの不正な持ち越し（Race Conditionに類似した論理バグ）を引き起こす可能性。
- コールスタック汚染:
Fiber内部で例外が発生し、それが適切にキャッチされずにバブルアップした場合、コンテキストスイッチのメタデータや例外トレース（`Throwable::$trace`）の中に、本来露出してはならないメモリ上の機密ポインタや内部構造体のアドレスが含まれるリスク。
セキュアなWebシステムを設計する上では、「Fiberはあくまでユーザーランドの非同期プログラミングの利便性を上げるための糖衣構文（あるいは協調的プリミティブ）であり、Cレベルのメモリ安全性やプロセス分離を強固にするものではない」という事実を深く認識しておく必要がある。
—
結言
PHPのFiberと `zend_fiber_context` は、長年静的かつ同期的な実行モデルを貫いてきたPHPエンジンにとって、パラダイムシフトとも言える低レイヤの偉業である。
CPUレジスタを直接ハンドリングし、独自のCコールスタックを動的に切り替えるこの仕組みを理解していればもはやPHPは単なる「お手軽なスクリプト言語」ではない。
極限まで最適化されたZend VMの内部構造を脳内に描き、メモリ空間の隅々までを掌握した上でアーキテクチャを設計すること。それこそが、真にスケーラブルで堅牢な次世代Webシステムを構築する唯一の道である。