Zend VMの実行スタックと限界：再帰呼び出しの崩壊と、スタックレス・イテレーションへのパラダイムシフト
PHPは「手軽なスクリプト言語」という薄い皮膜の下に、C言語で書かれた極めてシビアな仮想マシン（Zend VM）を隠し持っている。1つのHTTPリクエストがPHP-FPMのプロセスに飛び込んできた瞬間から、Zend Engineはソースコードを字句解析・構文解析し、抽象構文木（AST）を経て、CPUが効率的に解釈するための「オペコード（Opcode）」へと変換する。
このZend VMの挙動、特に「実行スタック（Execution Stack）」の物理的制約と、関数・メソッドの再帰呼び出しが引き起こすメモリ破壊のメカニズムを正確に理解しているエンジニアは少ない。
本稿では、Zend VMのコールスタックの内部構造にメスを入れ、なぜPHPにおいて「再帰呼び出し」が大規模データ処理の地雷となるのか、そしてそれを回避するためのイテレータパターンやFiberによるコンテキストスイッチの極意を、コアの視点から徹底的に解剖する。
—
1. Zend VMの実行スタックと関数コールの物理構造
Zend VMは、スタックベースの仮想マシンではなく、レジスタベースに近い動作をするスタックマシンである。PHPの関数やメソッドが呼び出されるたび、Zend EngineはC言語のヒープ（あるいはプロセススタック）上に `zend_execute_data` という極めて重要な構造体を積み上げていく。
`zend_execute_data` とコールフレーム
PHPで関数がネストして呼び出されると、Zend VMの実行コンテキストである `zend_execute_data` が次のように鎖状に繋がっていく。
/ Zend/zend_compile.h の概念モデル /
struct _zend_execute_data {
const zend_op opline; // 現在実行中のオペコードポインタ
zend_call_info call_info; // 呼び出し情報
zend_function func; // 実行中の関数構造体
zval symbol_table; // ローカルシンボルテーブル（HashTable）
void run_time_cache; // 実行時キャッシュ
zval EX(opline_num); // オペコード番号
zend_execute_data prev_execute_data; // 呼び出し元（Caller）へのポインタ
zval return_value; // 戻り値の格納先
};
この `prev_execute_data` を辿ることで、VMは呼び出し履歴（コールスタック）を維持している。しかし、ここにPHP特有の致命的な物理的制約が存在する。
CのコールスタックとZend VMスタックの二重の壁
PHPの関数呼び出しは、最終的にOSスレッドのC言語レベルのコールスタック（通常、Linuxデフォルトでは8MB程度）を消費する。
1. Zend VM自体の構造体オーバーヘッド: 1つの関数フレーム（`zend_execute_data`）とローカル変数を格納する `zval` の配列がヒープ上に確保される。
2. Cのスタックオーバーフロー: 無限再帰や深すぎる再帰（数千〜数万階層）に陥ると、C言語の関数フレームそのものがプロセススタックの限界を超え、おなじみのアボートエラー `Segmentation fault (core dumped)` または `Allowed memory size exhausted` が発生する。
OPcacheが有効であっても、このコールフレームの積み上げコスト自体が消えるわけではない。JIT（Just-In-Time Compilation）が有効化され、オペコードがネイティブマシン語（x86_64の機械語）にコンパイルされた場合であっても、CPUのハードウェアスタック（`RSP`レジスタ）を消費する事実に変わりはない。
—
2. 末尾再帰最適化（Tail Call Optimization）の幻想とPHPの現実
関数型言語（HaskellやScalaなど）や、高度な最適化を行うC/C++コンパイラ（GCC/Clangの `-O2` 以上）では、「末尾再帰（Tail Recursion）」を検出し、新しいスタックフレームを積む代わりに現在のフレームを再利用する TCO（Tail Call Optimization） が行われる。
しかし、Zend VMには、本質的な意味での末尾再帰最適化は存在しない。
以下の典型的な「アキュムレータ（累積値）を用いた末尾再帰風」のPHPコードを見てみよう。
/
function sum_tail_rec(int $n, int $accumulator = 0): int
{
if ($n <= 0) {
return $accumulator;
}
// 最後に自分自身を呼び出しているが、Zend VMはこの文脈を最適化しない
return sum_tail_rec($n - 1, $accumulator + $n);
}
// 実行してみる（$n = 100,000 を与えるとどうなるか）
try {
echo sum_tail_rec(100000);
} catch (\Throwable $e) {
echo "エラー捕捉: " . $e->getMessage() . “\n”;
}
なぜZend VMはこれを最適化できないのか？
1. 動的タイピングとシンボル解決: PHPは実行時まで変数の型や関数名がオーバーライドされる可能性（ダイナミックディスパッチ）を考慮し続けなければならない。スコープ内の関数が後から `runkit` やモディファイアによって書き換えられるリスクがあるため、コンパイル時にコールジャンプをアセンブリレベルの単純な `JMP` に置換することが極めて困難である。
2. GCとスコープのライフサイクル: Zend Engineのガベージコレクション（参照カウントと循環参照コレクタ）は、スコープ（`zend_execute_data`）単位で変数のライフサイクルを管理している。フレームを破棄せずに使い回す最適化は、エンジンの複雑性を爆発的に高めるため、実装されていない。
結果として、上記のコードに大きな値を渡すと、容赦なくスタックが破綻する。
—
3. 限界突破：イテレータパターンとスタックレス・アルゴリズムへの書き換え
大規模なツリー構造（組織図、カテゴリ階層、ASTなど）を走査する際、再帰処理は最も直感的だが、プロダクション環境のWebシステムにおいて「再帰の深さが入力データに依存する設計」はセキュリティ上の脆弱性（Denial of Service: DoS）に直結する。
これを回避するためには、明示的なヒープ上のスタック（Array）を用いた「イテレータパターン（非再帰的走査）」へ書き換えるのが、高負荷Webシステムの鉄則である。
実装例：安全な非再帰的ツリー走査（スタックエミュレーション）
/
class Node {
public function __construct(
public string $name,
public array $children = []
) {}
}
/
- Zend VMのスタックを消費しない、明示的ヒープスタックによる深さ優先探索（DFS）
/
function traverse_tree_iteratively(Node $root): \Generator
{
// PHPの配列をLIFO（後入れ先出し）のスタックとして利用する
$stack = [$root];
while (!empty($stack)) {
// 配列の末尾からポップ（Cのスタック操作をユーザーランドでエミュレート）
/ @var Node $current /
$current = array_pop($stack);
// 現在のノードをyieldで遅延評価（メモリ効率の最大化）
yield $current;
// 子要素をスタックに積む（右側の要素から積むことで、左から順に処理されるようにする）
$count = count($current->children);
for ($i = $count – 1; $i >= 0; $i–) {
$stack[] = $current->children[$i];
}
}
}
// — ベンチマーク・検証用データ構築 —
// 10万階層の深さを持つ危険なツリーを構築しても、スタックオーバーフローしない
$root = new Node(“Root”);
$curr = $root;
for ($i = 0; $i < 50000; $i++) {
$next = new Node("Node_{$i}");
$curr->children[] = $next;
$curr = $next;
}
// 実行
$count = 0;
foreach (traverse_tree_iteratively($root) as $node) {
$count++;
}
echo “正常に走査完了: 処理ノード数 = {$count}\n”;
メモリ効率とZend Engineの内部挙動
上記のコードでは、`\Generator`（ジェネレータ）とユーザーランドの配列（`$stack`）を使用している。
- メモリの一定化: ジェネレータは一度に全結果を配列としてメモリに展開せず、`yield` に到達するたびに制御を呼び出し元に戻す。これにより、数百万件のレコードや巨大なツリー構造であっても、メモリ使用量を数キロバイトの定数オーダー（$O(1)$）に抑えられる。
- HashTableの最適化: PHPの配列（`array`）は内部的に二重連結リストを持つ `HashTable` として実装されているが、末尾への追加・削除（`array_push` / `array_pop`）は極めて高速に動作するように最適化されているため、スタック構造体としてのパフォーマンスも十分に実用範囲内である。
—
4. Fiber（ファイバー）による並行処理とコンテキストスイッチの罠
PHP 8.1で導入された Fiber は、コールスタックをユーザーランドで制御する画期的な機能である。非同期I/Oやコルーチンベースの並行処理において、再帰的な処理とFiberを組み合わせることで、イベントループ駆動型のアーキテクチャを構築できる。
しかし、Fiberの内部構造を誤解していると、深刻なメモリリークやパフォーマンス劣化を引き起こす。
Fiberの内部スタックとコピーオーバーヘッド
Fiberは、OSスレッドのコールスタックとは別に、独自のFiber専用スタック領域（zend_execute_dataのチェーンを独立して保持）をヒープ上に確保する。
start(5000);
while (!$fiber->isTerminated()) {
echo “サスペンドポイント到達: {$value}\n”;
$value = $fiber->resume();
}
アーキテクトが知るべきFiberの限界
1. スタックの再割り当てコスト: Fiberが生成されるたびに、Zend Engineは内部で実行コンテキストを新しく割り当てる。無制限にFiberを乱造すると、Cのヒープ領域がフラグメンテーションを起こし、メモリ効率が著しく低下する。
2. 例外とデバッグの難易度: Fiber内部で発生したスタックオーバーフローや致命的エラーは、呼び出し元のメインスレッドのtry-catchブロックをバイパスして伝播することがあるため、例外ハンドリングの設計には細心の注意が必要である。
—
5. まとめ：極限のPHP開発における設計思想
PHPはもはや「動くだけの簡易言語」ではない。Zend VMの仕様、オペコードの生成メカニズム、そしてメモリ管理のライフサイクルを完全に掌握したエンジニアにとって、PHPは極めて強力なシステム記述言語となる。
- 再帰は禁忌と心得よ: 入力データに比例して深さが変わる再帰処理は、Zend VMのコールフレーム枯渇とCのスタックオーバーフローを引き起こすため、原則として禁止またはイテレータへの書き換えを行うこと。
- 大規模データにはGeneratorを強制せよ: メモリ使用量をフラットに保つため、遅延評価とスタックエミュレーションを組み合わせた設計を標準とすること。
- 裏側のコストを常に脳内トレースせよ: 1行のコードが、Zend VM上でどのような `zend_execute_data` を生み出し、どれだけのCヒープを消費するのか。その立体的なイメージを持つことこそが、真のWebシステムアーキテクトの条件である。