Fiberのスタック管理とコンテキストスイッチの低レイヤ実態：CPUキャッシュ・TLBへの影響とZend VMの真実
PHP 8.1で導入された`Fiber`は、非同期プログラミングのパラダイムを根本から変えた。しかし、表面的な「協調的マルチタスク（Cooperative Multitasking）」の利便性に酔いしれ、これがZend Engineのメモリ空間やCPUの物理的挙動にどのような負荷を与えているかを理解していないエンジニアが多すぎる。
本稿では、Fiberが独自のコールスタックを持つことによるメモリ管理のメカニズム、そしてコンテキストスイッチ時に発生するCPUキャッシュのコールド化とTLB（Translation Lookaside Buffer）のフラッシュという、極限の低レイヤにおけるオーバーヘッドを解剖する。
—
1. Zend VMにおけるFiberスタックの物理構造
伝統的なPHPの実行モデルは、1リクエストにつき1つのOSスレッド（またはプロセス）が割り当てられ、コールスタックはCのコールスタック（あるいはZend VMのエグゼキューションスタック）上でリニアに伸長・縮小する。
しかし、Fiberはこの常識を破壊した。Fiberはユーザースペースにおいて独自のスタックフレームを持つ。
/ Zend/zend_fibers.h の概念的構造 /
typedef struct _zend_fiber {
zend_object standard;
uint32_t flags;
zend_fiber_transfer status;
zend_fcall_info fci;
zend_fcall_info_cache fci_cache;
zend_fiber_stack stack;
// 実行コンテキストの保存領域
ucontext_t context;
// …
} zend_fiber;
ヒープ上に割り当てられる「偽りのスタック」
OSスレッドのスタックはカーネルによってガードされ、オーバーフロー時は致命的なシグナル（SIGSEGV）を飛ばすが、Fiberのスタックはヒープ（Heap）上に動的にアロケートされる。
`zend_fiber_stack`構造体は、デフォルトでおおよそ数キロバイト〜数十キロバイトのメモリブロックを `mmap` あるいは `malloc` で確保する。これはすなわち、Fiberを生成・破棄するたびに、Zend Memory Manager（ZMM）およびOSのヒープアロケータを直撃することを意味する。大量のFiberを乱用するアーキテクチャは、メモリフラグメンテーションの温床となる。
—
2. コンテキストスイッチの代償：CPUキャッシュとTLBの破壊
Fiberの最大のコストは、メモリの消費量ではない。CPUのハードウェアレイヤで発生する隠れたコストにある。
CPUキャッシュ（L1/L2/L3）のコールド化
CPUは、直近でアクセスしたメモリ領域をL1/L2/L3キャッシュに保持することで高速性を保っている。
通常の同期処理であれば、関数呼び出しやリターンにおいてローカル変数はキャッシュのヒット率が高い状態を維持する。
しかし、Fiber間でコンテキストスイッチが発生すると、実行コンテキスト（レジスタ状態、プログラムカウンタ、スタックポインタ）が強制的に切り替わる。
これに伴い、以下の現象が発生する：
1. キャッシュミスの急増: 切り替え先のFiberが使用するスタック領域やヒープ上のデータは、現在のCPUキャッシュに載っていない（コールドキャッシュ状態）。
2. メモリ帯域の圧迫: CPUはメインメモリ（DRAM）からデータをフェッチし直す必要が生じ、バスのレイテンシが跳ね上がる。
TLB（Translation Lookaside Buffer）への影響
さらに深刻なのが、TLB（仮想アドレスから物理アドレスへの変換キャッシュ）への影響だ。
OSスレッド間のコンテキストスイッチと比較すれば、ユーザーランドのFiberスイッチはプロセス空間（CR3レジスタの変更、すなわちページテーブルの切り替え）を伴わないため、TLB全体がフラッシュされるわけではない。
しかし、Fiberごとに異なるヒープ領域（スタック領域）を行き来することにより、TLBミスの局所的な発生率が上昇する。
特に、数千のFiberが細切れに実行されるような非効率な設計（Fiber Storm）では、CPUのMMU（Memory Management Unit）がアドレス変換のキャッシュミスに悩まされ、IPC（Instructions Per Cycle）が劇的に低下する。
—
3. 実コードによる検証：Fiberのオーバーヘッドとメモリ動態
以下のコードは、Fiberを用いた処理と、通常の逐次処理における挙動の差をシミュレートしつつ、Zend VMのメモリ管理の闇を暴くものである。
/
declare(strict_types=1);
// メモリ使用量のベースライン
$initialMemory = memory_get_usage(true);
$initialPeak = memory_get_peak_usage(true);
echo “— 初期メモリ状態 —\n”;
echo “Usage: ” . number_format($initialMemory) . ” bytes\n”;
echo “Peak: ” . number_format($initialPeak) . ” bytes\n\n”;
$fiberCount = 10000;
$fibers = [];
$startTime = hrtime(true);
// 1万個のFiberを生成（この時点でヒープ上にスタック領域が確保される）
for ($i = 0; $i < $fiberCount; $i++) {
$fibers[$i] = new Fiber(function (int $id): void {
// サスペンド前の処理
$value = $id 2;
// 実行権を一度親へ返す（コンテキストスイッチ1回目）
$received = Fiber::suspend($value);
// レジューム後の処理（ここでCPUキャッシュやスタックの切り替えが発生）
$result = $received + 1;
Fiber::suspend($result);
});
}
$midMemory = memory_get_usage(true);
echo "--- 10,000個のFiber生成後（実行前） ---\n";
echo "Usage: " . number_format($midMemory) . " bytes\n";
echo "差分 (ZMMヒープ増加量): " . number_format($midMemory - $initialMemory) . " bytes\n\n";
// Fiberの実行とサスペンドの嵐（コンテキストスイッチの多発）
foreach ($fibers as $id => $fiber) {
// 最初のスタート
$val = $fiber->start($id);
// レジュームして値を送り込む
$fiber->resume($val + 10);
}
$endTime = hrtime(true);
$duration = ($endTime – $startTime) / 1e6; // ミリ秒換算
echo “— 実行完了後 —\n”;
echo “処理時間: ” . number_format($duration, 2) . ” ms\n”;
echo “ピークメモリ: ” . number_format(memory_get_peak_usage(true)) . ” bytes\n”;
このコードが内部（Zend VM）で意味するもの
1. `new Fiber(…)` が実行された瞬間、PHP内部では `zend_fiber_ctor` が走り、ヒープ上にスタック用のメモリブロックと `zend_object` が構造化される。
2. `start()` および `resume()` が呼ばれるたびに、Zend VMの実行ステート（`zend_execute_data`）とCPUレジスタ退避を含む低レイヤのコンテキストスイッチ関数（`zend_fiber_switchContext`）が呼び出される。
3. これにより、CPUパイプラインのストールや分岐予測のミス（Branch Misprediction）が誘発され、純粋な演算処理速度は「愚直なループ処理」よりも確実に低下する。
—
4. アーキテクトとしての実践的警鐘：Fiberをどこで使うべきか
「非同期だから速い」という短絡的な思考は、Webシステムアーキテクトとして最も警戒すべきアンチパターンである。
- CPU-boundな処理にFiberを持ち込んではならない:
暗号化処理、画像処理、複雑なアルゴリズムの計算などは、コンテキストスイッチのオーバーヘッド（キャッシュミス、TLB汚染）がそのまま性能劣化として直撃する。
- I/O-boundな処理の「多重化」にのみ用いる:
データベースへのクエリ待ち、HTTPリクエストの非同期並行実行など、「CPUが待機している時間（Stall Time）」を有効活用する場合にのみ、Fiberはその真価を発揮する。
OPcacheとプリローディングの文脈における注意
OPcacheプリローディング（`opcache.preload`）によって、スクリプトのバイトコードは共有メモリ（SHM）上に永続化され、リクエストごとのパースコストが消滅する。
しかし、Fiberが保持するスタックや実行中のローカル変数はリクエスト固有（あるいはFiberインスタンス固有）のヒープデータであるため、共有メモリの恩恵を直接受けにくい。プリロードされたクラスのメソッド内でFiberを使う場合であっても、インスタンス化コストとコンテキストスイッチの物理的コストは厳然と存在し続ける。
—
5. 結び：低レイヤの物理制約を支配せよ
PHPは「手軽なスクリプト言語」から、JITコンパイラやFiberを備えた「高度なランタイム」へと進化を遂げた。しかし、CPUの物理的限界（キャッシュ階層、メモリバンド幅、TLBのサイズ）を無視したコードが高速に動作することは絶対にない。
真に優れたWebシステムアーキテクトは、コードの美しさだけでなく、Zend VMが生成するオペコードの挙動と、それがハードウェアのシリコン上で引き起こす熱と電気の挙動までを脳内でトレースできなければならない。Fiberを実装する際は、その背後にある「コンテキストスイッチの重み」を常に意識し、システム全体のスループットを最大化する設計を選択せよ。