PHP 8.x FiberにおけるZend VM実行スタックとFiberスタックの物理共存メカニズム
PHP 8.1における `Fiber`（ファイバー）の導入は、長らくPHPエコシステムを縛り付けてきた「1リクエスト＝1スレッド（あるいは同期型プロセスモデル）」という呪縛に対する、Zend VMレベルでの静かなる革命であった。Node.jsのイベントループやGoのGoroutineに慣れ親しんだエンジニアが、ついにPHPの文脈のままスタックフルな協調的マルチタスク（Cooperative Multitasking）を手に入れた瞬間でもある。
しかし、フレームワークが提供する抽象化層の裏側で、Zend VMが物理メモリ上で何を行っているかを正確に理解しているエンジニアは極めて少ない。`Fiber::suspend()` がコールされた瞬間、C言語レベルのコールスタックとZend VMの実行コンテキストはどこへ消え、どうやって復活するのか。
本稿では、Zend VMの内部構造、実行スタック（`zend_execute_data`）の物理的配置、そしてFiberがメモリ上で果たす役割の真髄を、極限の低レイヤ視点から解き明かす。
—
1. Zend VMの通常実行モデルと `zend_execute_data` の正体
PHPのコードが実行される時、Zend VMはC言語のコールスタック上で動的な関数呼び出しツリーを構築する。この中核を担うのが `zend_execute_data` 構造体である。
通常の同期実行においては、PHPの関数やメソッドが呼び出されるたびに、Cのヒープまたはスタック上に新しい `zend_execute_data` がアロケートされ、これが連結リスト（あるいはポインタチェーン）を形成する。
/ Zend/zend_compile.h および zend_execute.h の概念的構造 /
struct _zend_execute_data {
const zend_op opline; // 現在実行中のopcodeへのポインタ
zend_function func; // 現在実行中の関数/メソッドの定義
zval symbol_table; // ローカルシンボルテーブル
void run_time_cache; // キャッシュ
zval object; // $this ポインタ
zend_execute_data prev_execute_data; // 呼び出し元のスタックフレームへのポインタ
zval return_value; // 戻り値の格納先
};
1リクエストのライフサイクルにおいて、PHPのメインスクリプトから深部の子関数へ潜っていくにつれ、この `prev_execute_data` をたどるチェーンがCのコールスタック（あるいはZend VM専用のエグゼキューションスタック）上に積み上がっていく。
ここに重大な制約があった。従来のPHPでは、ある関数の中で重いI/O待ちが発生した場合、そのCコールスタックおよび `zend_execute_data` チェーンを保持したまま処理を中断し、別の処理へコンテキストを切り替えることが不可能だったのだ。Cのスタックポインタ（`rsp`）が現在の関数フレームを指している以上、それを勝手に別の場所に退避させて別処理を動かすことは、C言語のABI（Application Binary Interface）上、極めて困難だったからである。
—
2. Fiber導入による実行モデルのパラダイムシフト
PHP 8.1で実装された Fiber は、この Zend VM の実行コンテキストを「第一級オブジェクト」として切り離すことに成功した。
Fiberの本質は、「独自の `zend_execute_data` チェーンおよびVMスタックの退避先をヒープ上に確保し、C言語レベルのファイバー（Boost.Context等のアセンブリレベル、あるいはPHPコアに組み込まれた専用のコンテキストスイッチ機構）と調停する仕組み」である。
以下のコードを見てほしい。一見するとただの非同期風の処理だが、内部で何が起きているかをエンジニアの脳内で物理的にトレースできなければならない。
/
$fiber = new Fiber(function (string $name): string {
echo “[Fiber] 開始: {$name}\n”;
// 最初のサスペンド：呼び出し元へ制御を返す
$dataFromMain = Fiber::suspend(“最初のサスペンドからのデータ要求”);
echo “[Fiber] レジュームされました。受け取ったデータ: {$dataFromMain}\n”;
return “Fiber完了の戻り値”;
});
// メイン文脈での実行開始
echo “[Main] ファイバーをスタートします\n”;
$valueFromFiber = $fiber->start(“ZendVM-Context”);
echo “[Main] Fiberから受け取った値: ‘{$valueFromFiber}’\n”;
// 処理をファイバーに戻す
echo “[Main] Fiberにデータを送り返して再開します\n”;
$finalResult = $fiber->resume(“メインからの注入データ”);
echo “[Main] Fiberの最終戻り値: ‘{$finalResult}’\n”;
物理的挙動のトレース
1. `$fiber->start()` の呼び出し:
Zend VMは、メインスクリプトの実行コンテキスト（`EG(current_execute_data)`）とは別に、Fiber専用の仮想スタック空間をヒープ上に割り当てる。この中には、クロージャ内で展開されるローカル変数、オペコードの実行位置を指す `opline`、そして `zend_execute_data` の新しいルートが含まれる。
2. `Fiber::suspend()` の到達:
Fiberの内部から `suspend()` がコールされると、Zend VMは現在の `zend_execute_data` の状態（どのオペコードまで実行したか、ローカル変数のzvalの状態など）をそのまま凍結（Freeze）する。
3. コンテキストスイッチ:
Cレベルの実行コンテキストがメインスレッド側に巻き戻され、`$fiber->start()` の呼び出し元へ制御が戻る。この時、Cのコールスタック自体は破棄されず、Fiber専用の構造体（`zend_fiber_context`）の中に仮想的なスタック状態が安全に退避・保持される。
—
3. Zend VM内部におけるメモリ配置とスタックの共存メカニズム
PHPのソースコード（Zendエンジン）の内部を覗くと、Fiberは `zend_fiber` 構造体として表現されている。
/ Zend/zend_fiber.h (概念的表現) /
typedef struct _zend_fiber {
zend_object standard;
zend_fiber_status status;
zend_fcall_info fci;
zend_fcall_info_cache fci_cache;
// ファイバー固有のVMスタックと実行データ
zend_execute_data execute_data;
zend_vm_stack stack;
// 低レイヤのコンテキスト管理（プラットフォーム依存）
zend_fiber_transfer context;
// …
} zend_fiber;
通常のスクリプト実行では、VMスタックはグローバルあるいはリクエストごとの単一の連続したメモリチャンク（メモリプール）上に順次積み上げられる。しかし、Fiberが複数存在する場合、それぞれのFiberは独自の `zend_vm_stack` チャンクを持つ。
メモリの俯瞰図
[ PHP Request Memory (Zend MM) ]
├── Global Execution Context (Main script)
│ └── zend_execute_data (Main) ──> [ VM Stack (Main) ]
│
└── Fiber 1 Object (Heap)
├── zend_fiber 構造体
└── Fiber Context
├── zend_execute_data (Fiber内部) ──> [ 専用 VM Stack (Fiber 1) ]
└── 独自のリロケータブルスタック領域 (Heap上にアロケート)
Fiberがサスペンドすると、Zend VMのグローバル変数である `EG(current_execute_data)` は呼び出し元のメインコンテキストを指すように書き換えられる。これにより、CPUやZend VMから見れば「あたかも通常の関数からリターンしたかのように」振る舞いながら、内部的にはFiberのコンテキストデータが完全にヒープ上に温存されることになる。
この仕組みにより、OSスレッドをブロックすることなく、数千、数万の並行タスクをPHPのシングルスレッドプロセス内で擬似的に同時実行することが可能になるのだ。
—
4. アーキテクチャ上の罠：Fiber利用時のセキュリティとメモリリークの温床
ここで、最高峰のアーキテクトとして警鐘を鳴らさなければならない。Fiberは強力な非同期プリミティブである反面、そのメモリ管理の特殊性から、従来のPHPプログラミングでは想定しなかった脆弱性や致命的なバグを生む温床になり得る。
A. オブジェクトインジェクションとガジェットチェインの変質
従来のPHPセキュリティにおいて、オブジェクトインジェクション（`unserialize()` の悪用など）は、主にリクエストのライフサイクルが単一の同期ストリームであることを前提としたマジックメソッド（`__destruct` や `__wakeup`）の連鎖（Gadget Chain）によって成立していた。
しかし、Fiberや非同期イベントループ（AmpやReactPHP等）を導入したシステムでは、「オブジェクトの破棄タイミングが予測不可能になる」という問題が発生する。
Fiber内で保持されているスコープ外のオブジェクトや、未完了のまま宙に浮いた `zend_execute_data` 内のローカル変数は、Fiberが完全にガベージコレクションされるか破棄されるまでメモリ上に残り続ける。もし、悪意ある入力によって不正に構築されたFiberコンテキストが意図せず永続化されたり、不適切なタイミングでレジュームされた場合、メモリ上のゾンビ状態のオブジェクトが予期せぬマジックメソッドの実行を引き起こし、新たなタイプのインジェクションベクターを形成するリスクがある。
B. スタックオーバーフローとメモリ断片化
Fiberのスタックは初期化時に一定のサイズ（デフォルトでは通常数KB〜数十KB、PHPの内部設定やシステムに依存）でヒープ上に確保される。
無限再帰や、Fiber内での巨大なローカル変数の過剰な蓄積（巨大な配列の処理など）が発生した場合、通常のCスタックオーバーフローではなく、Fiber専用のVMスタック領域の枯渇を引き起こす。これはZend VMのメモリマネージャー（ZendMM）を巻き込んだクラッシュを引き起こし、FPMプロセスの即座のセグメンテーション違反（Segmentation Fault）に直結する。
—
5. 実戦的極意：高パフォーマンスなFiberイベントループの設計
実務においてFiberを単体で使うことは少なく、何らかのイベントループ（例: Revolt等）と組み合わせて非同期I/Oを実現する。最後に、Zend VMのオーバーヘッドを最小限に抑え、コンテキストスイッチのコストを極限まで削ぎ落としたアーキテクチャの骨組みを示す。
/
public static function go(callable $task, mixed …$args): void
{
$fiber = new Fiber(function() use ($task, $args) {
try {
// タスクの実行
$task(…$args);
} \Throwable $e {
// 内部例外のキャッチとログ出力（プロセス全体のクラッシュを防ぐ防壁）
self::handleException($e);
}
});
// イベントループのTickにFiberの初期実行をアタッチ
EventLoop::queue(static function() use ($fiber) {
try {
if ($fiber->isSuspended()) {
$fiber->resume();
} elseif ($fiber->isStarted() === false) {
$fiber->start();
}
} \Throwable $e {
self::handleException($e);
}
});
}
private static function handleException(\Throwable $e): void
{
// 本来はここで構造化ロガー（Monolog等）へ出力
error_log(sprintf(“[AsyncKernel Error] %s in %s:%d”, $e->getMessage(), $e->getFile(), $e->getLine()));
}
}
// — 使用例 —
// 実際のプロダクションコードでは、ここで非同期ソケットやDBドライバからのsuspendを挟む
AsyncKernel::go(function () {
echo “タスク1: 非同期処理の開始\n”;
// 擬似的な非同期I/O待ち（実際はイベントループ経由でsuspendされる）
$result = (new class {
public function await(): string {
$fiber = Fiber::getCurrent();
EventLoop::delay(0.1, static fn() => $fiber->resume(“非同期I/O完了データ”));
return Fiber::suspend();
}
})->await();
echo “タスク1: 完了 -> {$result}\n”;
});
// イベントループの駆動
// EventLoop::run(); // 実際の環境ではここでループを回す
結びにかえて
PHPのFiberは、単なる「便利な言語機能」ではない。それは、Zend VMのメモリ構造とC言語レベルのスタック管理の境界線を鮮やかに書き換え、PHPを真の意味での「高並行処理ランタイム」へと昇華させた歴史的転換点である。
エンジン内部で `zend_execute_data` がどう舞い、ヒープ上の仮想スタックがどう切り替わっているか。その物理的なイメージを脳内に焼き付けたエンジニアだけが、極限のパフォーマンスと堅牢性を兼ね備えたWebシステムアーキテクチャを構築できる。コードの表面をなぞるだけの時代は終わった。PHPの鼓動を、低レイヤのさらに深くまで掌握せよ。