【実務・中級編】Fiber（ファイバー）のスタック管理とコンテキストスイッチのオーバーヘッド：CPUキャッシュとTLB（Translation Lookaside Buffer）への影響 – PHPコア・内部エンジンと高速化・並行処理の極意解析バイブル

PHP 8 Fiberの深淵：スタック管理の物理限界と、コンテキストスイッチがCPUを殺す理由

コードレビューにおいて、「PHP 8でFiberが入ったから、I/O待ちの多いAPIは全部非同期に書き換えよう」という提案を受け取ったことはないだろうか。もし君がテクニカルリードなら、そのプルリクエストを即座に止めるべきだ。

世間の技術記事は「Fiberを使えばコールバック地獄から解放される」「軽量な並行処理ができる」という表層的なメリットしか語らない。しかし、Zend VMのソースコードをめくり、CPUのシリコンダイ上で何が起きているかを想像したことがあるだろうか。

今回は、Fiberがメモリ空間とハードウェア（CPUキャッシュ、TLB）に与える破壊的な影響を低レイヤの視点から暴き、実務で絶対に踏んではいけない設計の地雷について解説する。

—

1. Zend VMにおけるFiberスタックの正体

传统的なPHP（PHP 7以前、あるいはFiber未導入の環境）では、すべての実行コンテキストはCのコールスタック（あるいはZend Executorのグローバルな実行スタック）上で連続的に処理されていた。関数が呼ばれればスタックポインタ（`ZEND_VM_STACK`）が動き、リターンすれば巻き戻る。この構造はキャッシュメモリにとって極めて親和性が高い。

しかし、PHP 8で導入された `Fiber` は、独立したヒープ割り当て領域に独自のスタックを持つ。

Fiberが生成されるとき、Zend Engineは `emalloc()` を用いてスタック領域をヒープ上に確保する。デフォルトでは、このスタックサイズはプラットフォーム依存だが、数キロバイトから数十キロバイトの塊となる。

ここで最初の問題が発生する。「ヒープ上に散らばった別々のスタックを行き来する」ということは、CPUのプログラムカウンタとスタックポインタがメモリ空間を大きくジャンプすることを意味する。

—

2. コンテキストスイッチが引き起こすハードウェアの悲劇

Fiberの `suspend()` と `resume()` が実行される瞬間、Zend VMは以下のような重い処理を行っている。

1. 現在の `zend_execute_data` の状態を退避。
2. レジスタや実行コンテキストの切り替え（C言語レベルでのジャンプ）。
3. 移行先のFiberのスタックポインタと実行ポインタの復元。

この「コンテキストスイッチ」の代償は、ソフトウェア層にとどまらない。ハードウェア（CPU）レベルで致命的なボトルネックを生み出す。

① L1/L2/L3キャッシュの汚染 (Cache Pollution)

CPUは、直近でアクセスしたメモリ領域をキャッシュ（L1/L2/L3）に保持することで高速性を保っている。メインの実行フローからFiberへジャンプし、さらに別のFiberへコンテキストスイッチを繰り返すと、CPUキャッシュ内に存在しないメモリ領域へのアクセスが急増する。
結果として キャッシュミス（Cache Miss） が多発し、メインメモリ（DRAM）からのレイテンシがパフォーマンスを直撃する。

② TLB（Translation Lookaside Buffer）ミスの激発

仮想アドレスを物理アドレスに変換するキャッシュ機構であるTLBは、CPUの性能手綱を握る極めて重要なリソースだ。
Fiberが無数に生成され、ヒープ上のあちこちのスタック領域に頻繁にジャンプすると、TLBのエントリが頻繁に書き換わる。これが TLBスラッシング（TLB Thrashing） を引き起こし、CPUサイクルが無駄なアドレス変換に浪費される。

—

3. 【アンチパターン】実務でやってはいけないFiberの乱用

「リクエストごとに数千個のFiberを生成して並行処理させる」という設計は、ハードウェアの観点からは 自爆行為 だ。

以下のコードを見てほしい。一見、効率的に並行処理を行っているように見えるが、内部で何が起きているかを想像してほしい。

【危険なアンチパターン例】

大量のHTTPリクエストを数千のFiberで同時に処理しようとする設計

declare(strict_types=1);

class DangerousAsyncWorker
{
/

@param string[] $urls

/
public function concurrentFetch(array $urls): array
{
$fibers = [];
$results = [];

foreach ($urls as $id => $url) {
// 各タスクごとにFiberを生成（メモリとCPUキャッシュへの爆弾）
$fibers[$id] = new Fiber(function () use ($url) {
// 何らかの非同期I/O（ここでは模擬的にsleepやcurlを想定）
// 実際にはここでsuspendが発生し、コンテキストスイッチが起きる
return $this->mockAsyncHttpCall($url);
});
}

// 全Fiberを起動
foreach ($fibers as $fiber) {
$fiber->start();
}

// 完了を待機（ビジネスカウントやイベントループの欠如）
$running = true;
while ($running) {
$running = false;
foreach ($fibers as $id => $fiber) {
if (!$fiber->isTerminated()) {
$running = true;
// 頻繁なresume/suspendの往復がCPUを焼き尽くす
if ($fiber->isSuspended()) {
$results[$id] = $fiber->resume();
}
}
}
}

return $results;
}

private function mockAsyncHttpCall(string $url): string
{
// 実際の非同期I/O待機をシミュレート
Fiber::suspend();
return “Response from {$url}”;
}
}

なぜこのコードがプロダクションで破綻するのか？

1. メモリ断片化の加速: 数千個のFiberスタックが `emalloc()` でヒープ上に確保・解放されるため、Zend Memory Managerに深刻な負荷がかかり、メモリフラグメンテーションを引き起こす。
2. CPUバウンドの罠: CPUコア数を超える数のFiberがコンテキストスイッチを繰り返すと、OSのスレッド切り替えと同様に、コンテキストスイッチのオーバーヘッドが実処理の時間を超過する「スラッシング状態」 に陥る。

—

4. 【実務向け】ハードウェア特性を考慮した堅牢なFiber制御設計

では、PHPにおけるFiberはどのように使えば実用的なのか。
答えは 「プーリング」 と 「バッチ処理による粒度の制御」 だ。CPUキャッシュとTLBへのインパクトを最小限に抑えるため、同時にアクティブになるFiberの数を制限（レートリミット）し、ヒープアロケーションの頻度を抑える設計が求められる。

以下に、実務のAPIゲートウェイやクローラー基盤などで耐えうる、堅牢なFiberプールのリファレンスコードを提示する。

【実務向け堅牢設計】コンセプチュアル・Fiberプールプロセッサ

同時実行数を制限し、CPUキャッシュとメモリへの負荷を制御する

declare(strict_types=1);

namespace System\Architecture\Concurrency;

use Fiber;
use Generator;
use Throwable;

class ControlledFiberPool
{
private int $maxConcurrency;
/ @var array /
private array $pool = [];

public function __construct(int $maxConcurrency = 10)
{
// ハードウェアの論理コア数やI/O特性に合わせて同時に動くFiber数を制限する
$this->maxConcurrency = max(1, $maxConcurrency);
}

タスクをキューに登録する

/
public function addTask(callable $task, mixed $payload): void
ジェネレータやタスクキューへ積む（今回はシンプルに配列保持）
{
$this->pool[] = [
‘fiber’ => new Fiber($task),
‘callback’ => $task,
‘payload’ => $payload,
];
}

制御された並行度でタスクを実行し、結果を回収する
@return Generator

/
public function execute(): Generator
{
$activeFibers = [];
$queue = $this->pool;

while (!empty($queue) || !empty($activeFibers)) {
// 同時実行数制限に達するまで、キューからFiberを取り出して起動
while (count($activeFibers) < $this->maxConcurrency && !empty($queue)) {
$taskData = array_shift($queue);
/ @var Fiber $fiber /
$fiber = $taskData[‘fiber’];

try {
// 初回実行（ここでFiberスタックが初期化・稼働開始）
$result = $fiber->start($taskData[‘payload’]);

if ($fiber->isSuspended()) {
// サスペンドした場合はアクティブプールでイベント待ち受け状態に
$activeFibers[] = $fiber;
} else {
// 即座に完了した場合
yield $result;
}
} catch (Throwable $e) {
// エラーハンドリング：スタックの巻き戻しとログ記録
yield $e;
}
}

// アクティブなFiberの再開処理（シミュレーション）
foreach ($activeFibers as $index => $fiber) {
if ($fiber->isSuspended()) {
try {
// 外部イベントやI/O完了を模してレジューム
$result = $fiber->resume();
if ($fiber->isTerminated()) {
unset($activeFibers[$index]);
yield $result;
}
} catch (Throwable $e) {
unset($activeFibers[$index]);
yield $e;
}
} elseif ($fiber->isTerminated()) {
unset($activeFibers[$index]);
}
}

// CPUのビジータスクによる無駄なサイクル消費を防ぐための極小ウェイト
// (実際のEvent Loopではepoll/kqueueのタイムアウトに相当)
usleep(1000);
$activeFibers = array_values($activeFibers);
}
}
}

// ==========================================
// 実行例・動作検証コード
// ==========================================
/
$pool = new ControlledFiberPool(maxConcurrency: 3);

// タスクの登録
for ($i = 1; $i <= 10; $i++) { $pool->addTask(function (int $id) {
echo “Task {$id}: 開始\n”;
// 非同期処理の擬似的な中断
Fiber::suspend();
echo “Task {$id}: 再開・処理継続\n”;
usleep(50000); // 50msの作業を想定
return “Result_{$id}”;
}, $i);
}

// 実行と結果の回収
foreach ($pool->execute() as $output) {
if ($output instanceof Throwable) {
echo “エラー発生: ” . $output->getMessage() . “\n”;
} else {
echo “完了: {$output}\n”;
}
}
/

—

5. テクニカルリードからの総括：Fiberと正しく向き合うために

PHPにおけるFiberは、Node.jsのAsync/AwaitやGo言語のGoroutineとは決定的に異なる。GoのGoroutineはGoランタイムがOSスレッド上で効率的にスケジュール・多重化するが、PHPのFiberは あくまでZend VM上で協調的マルチタスク（Cooperative Multitasking）を実現するプリミティブ に過ぎない。

ハードウェアレベルで言えば、Fiberの導入は「メモリ空間の細分化」と「キャッシュヒット率の低下」というトレードオフを確実に生む。

安易に数千のFiberを立てるな。（メモリフラグメンテーションとTLBミスの温床になる）
I/Oの多重化（Event Loop）と組み合わせた適切な粒度（プーリング）で制御せよ。
プロファイリングツール（Xdebugや各種APM）を使い、コンテキストスイッチのオーバーヘッドが実処理時間を圧迫していないか常に監視せよ。

「新機能だからとりあえず使う」のではなく、「それがZend VMとハードウェアにどのような負荷を与えるか」を脳内で完璧にシミュレートできる者だけが、真にスケーラブルなPHPアプリケーションを構築できる。コードレビューの基準を、今日から一段引き上げよう。