PHPターゲットにおける非同期パラダイムの断絶
クロスプラットフォーム言語としてのHaxeの強みは、あらゆるターゲットの実行モデルに対して柔軟な抽象化レイヤを構築できる点にある。しかし、長年PHPターゲット（`haxe -php`）は、言語仕様の根底にある「シェアードナッシング」および「完全同期型ブロッキングI/O」というWeb黎明期からの設計思想に縛られてきた。
JavaScript targetであれば単一のEvent LoopとMicrotask Queue（`Promise`）に自然にマッピングされ、C++ targetであればスレッドプールやOSネイティブのプリエンプティブスレッドに委譲できる。これに対し、PHPにおける非同期処理は、長らく`ext-uv`や`Swoole`などの拡張モジュール、あるいは`amphp`や`ReactPHP`のようなユーザランドのジェネレータ（`Generator`）ベースの協調的マルチタスクに依存せざるを得なかった。ジェネレータによる非同期エミュレーションは、いわゆる「関数の着色問題（Function Coloring Problem）」を引き起こし、Haxeの静的型システムおよびASTレベルでのインライン展開と極めて相性が悪かったのである。
この地殻変動を起こしたのが、PHP 8.1でコアに導入された`Fiber`（スタックフルコルーチン）である。
+————————————————————-+
| Haxe High-Level Async Model (tink_core / Future / Promise) |
+————————————————————-+
│
(Transpile & Zero-Cost Abstraction)
▼
+————————————————————-+
| Low-Level Haxe-PHP Fiber Bridge |
| – Custom Event Loop Driver (epoll/select or React/Amp core) |
| – Abstract-driven Suspender (await semantics) |
+————————————————————-+
│
(Zend VM Execution)
▼
+————————————————————-+
| PHP 8.1+ Zend Fiber Subsystem |
| – C-Stack & Zend VM Frame (`zend_execute_data`) Switch |
| – Boost.Context-based ucontext/fiber context switching |
+————————————————————-+
本稿では、Haxeの非同期モデル（`tink_core`の`Future`/`Promise`や独自のCPS変換）をPHP 8.1の`Fiber`にマッピングする際、Zend Engine内部で何が起きているのか、メモリ管理（Zend Memory Manager）とコールスタックの観点から徹底的に解剖する。
—
トランスパイルとFiberブリッジの低レイヤアーキテクチャ
HaxeのFuture/PromiseモデルをFiber上で同期的にアンラップ（`await`）可能にするためには、Futureの解決（Resolve）コールバックをFiberの再開（`resume`）に結びつけ、未解決状態では即座にサスペンド（`suspend`）するランタイムブリッジが必要となる。
Zero-Cost Suspenderの実装
以下のコードは、Haxeの抽象型（`abstract`）とインライン化を極限まで活用し、オーバーヘッドを最小限に抑えつつ`Future
package runtime.async;
if !php
error “This low-level fiber bridge is only available for PHP 8.1+ targets.”
end
import php.Syntax;
/
- PHP 8.1+ のネイティブ \Fiber をラップする低レイヤクラス。
- extern を介してZend Fiber APIに直接バインドする。
/
@:native(“\\Fiber”)
extern class NativeFiber {
public function new(callback:haxe.Constraints.Function):Void;
public function start(args:haxe.Rest
public function resume(value:Dynamic = null):Dynamic;
public function throw(exception:php.Throwable):Dynamic;
public function isStarted():Bool;
public function isSuspended():Bool;
public function isRunning():Bool;
public function isTerminated():Bool;
public static function suspend(value:Dynamic = null):Dynamic;
public static function getCurrent():Null
}
/
- コールバック駆動のFuture実装（最小限のコア抽象）
/
class Future
private var handler:Null<(T -> Void) -> Void>;
private var result:Null
private var isDone:Bool = false;
public inline function new(handler:(T -> Void) -> Void) {
this.handler = handler;
}
public inline function handle(cb:T -> Void):Void {
if (this.isDone) {
cb(this.result);
} else {
this.handler((val:T) -> {
this.result = val;
this.isDone = true;
cb(val);
});
}
}
/
- 現在のコンテキスト（Fiber）を一時停止し、Futureの解決時に再開する。
- ループの外側から見れば完全な同期ブロッキング関数として振る舞う。
/
public function await():T {
// メインスレッド（Fiber外）でのawait呼び出しを検知してフォールトさせる
var currentFiber = NativeFiber.getCurrent();
if (currentFiber == null) {
throw new haxe.Exception(“FiberAsyncBridge: Cannot await outside of an active Fiber context.”);
}
if (this.isDone) {
return this.result;
}
var fiberRef = currentFiber;
var hasResumed = false;
var failure:Null
// 非同期完了時にFiberをResumeするハンドラを登録
this.handle((val:T) -> {
if (!hasResumed) {
hasResumed = true;
if (fiberRef.isSuspended()) {
fiberRef.resume(val);
}
}
});
// Fiberを中断。戻り値はresume()の第1引数から注入される
var asyncResult:T = NativeFiber.suspend();
return asyncResult;
}
}
生成されたPHPコードの検証
上記Haxeコードをコンパイルした際、HaxeのPHPジェネレータは次のようなネイティブコードを出力する。
// Haxeコンパイラが出力するawait()メソッドのトランスパイル結果（抜粋）
public function await() {
$currentFiber = \Fiber::getCurrent();
if ($currentFiber === null) {
throw new \Exception(“FiberAsyncBridge: Cannot await outside of an active Fiber context.”);
}
if ($this->isDone) {
return $this->result;
}
$fiberRef = $currentFiber;
$hasResumed = false;
$this->handle(function ($val) use (&$hasResumed, &$fiberRef) {
if (!$hasResumed) {
$hasResumed = true;
if ($fiberRef->isSuspended()) {
$fiberRef->resume($val);
}
}
});
return \Fiber::suspend();
}
ここで注目すべきは、クロージャ捕捉における参照変数 `&$hasResumed` および `&$fiberRef` の挙動である。Haxeは参照の寿命をスコープ全体で厳密に追跡するが、PHPの参照カウントガベージコレクション（Zend GC）においては、この参照キャプチャがFiberのスタック退避・復帰と複雑に絡み合う。
—
スタック管理とコンテキストスイッチの深淵
Haxeレイヤでは単なる「関数の待機」に見える操作も、Zend VMの内部ではOSネイティブのCスタックの切り替えとVM実行コンテキスト（`zend_execute_data`）の退避・付け替えという、極めて重厚な低レイヤ処理が実行されている。
[ Zend Engine Memory Space ]
│
┌───────────────────────────────┴───────────────────────────────┐
▼ ▼
[ Root Execution Context ] [ Fiber Execution Context ]
┌──────────────────────────┐ ┌──────────────────────────┐
│ C-Stack (Native OS Frame)│ │ C-Stack (Allocated 4KB+) │
│ – RSP/RBP Pointers │ <=== Context ===> │ – Independent Call Stack │
│ – CPU General Registers │ Switch │ – Boost.Context / asm │
├──────────────────────────┤ (fiber_switch) ├──────────────────────────┤
│ Zend VM Stack │ │ Zend VM Stack │
│ – EG(current_execute_data│ │ – Separate VM Stack Page │
│ – Local zval variables │ │ – Independent Call Chain │
└──────────────────────────┘ └──────────────────────────┘
1. `fiber_switch` と Cスタックの退避
PHP 8.1のFiberは、Boost.Contextに類似したアーキテクチャ（x86-64ではアセンブリによるレジスタ退避ルーチン）を採用している。
1. `\Fiber::suspend()` が呼び出されると、Zend Engine内部の `zend_fiber_switch_to` が発火する。
2. 実行中のレジスタセット（RSP, RBP, RBX, R12-R15等）が現在のFiberのスタック領域（通常デフォルトでCスタックとして割り当てられたページ）に`push`退避される。
3. `EG(current_execute_data)`（Zend VMの現在のフレームポインタ）がFiberの実行状態構造体（`zend_fiber_context`）に保存され、呼び出し元（スケジューラ側）の `zend_execute_data` に差し替えられる。
4. CPUのスタックポインタがスケジューラ側のCスタックに切り替わり、処理が戻る。
Haxeから見ると、これは「式を評価した瞬間にVMがフリーズし、後から値が降ってくる」ように見えるが、メモリ上では完全に独立した2つのCコールスタックが並行して存在している。
2. Zend VM StackのページングとHaxeのディープ再帰
Haxeの強力なインライン展開や複雑なパターンマッチングは、コンパイル時に深いコールツリーを生成することがある。
PHPの標準VMスタック（`zend_vm_stack`）は、256KB程度のページ単位で動的にチェインされる。しかし、Fiberごとに独立したVMスタックページが割り当てられるため、大量のFiber（数万オーダー）を生成し、かつそれぞれのFiber内でHaxeの深いネストを実行すると、メモリの断片化と`fiber.stack_size`の急激な枯渇を招く。
; php.ini でのチューニング指標
; デフォルトのスタックサイズ（バイト単位）。ディープなコールスタックを伴うHaxe処理では調整必須
fiber.stack_size = 131072 ; 128KB に抑えて大量並行性を確保する、あるいは再帰深度に応じて拡大
—
メモリリークと循環参照の防壁
Fiberを導入したHaxe/PHPアーキテクチャにおいて、最も警戒すべきは「Fiberを跨いだ循環参照によるZend GCの機能不全」である。
循環参照が引き起こすメモリリークの構造
Haxeで記述した非同期ハンドラが、自身を包含するFiberインスタンスへの参照をキャプチャし、そのFutureが何らかの理由（外部ネットワークのタイムアウト等）で解決されなかった場合、以下の参照ループが完成する。
[ Active Fiber Context ] ──(references)──> [ Haxe Closure / Future ]
▲ │
│ │
└──────────(captures $fiberRef)─────────────┘
通常の同期コードであれば、スコープを抜けた時点でリファレンスカウンタがデクリメントされ、ゼロになった時点で即座に`zval_ptr_dtor`が走る。
しかし、Fiberが`SUSPENDED`状態のまま放置された場合、そのFiberのCスタックおよびZend VMスタックフレーム上に積まれたすべてのローカル変数（`zval`）はルートセットとして生存し続ける。Zend Garbage Collector（Cycle Collector）は、実行中のコールスタックから到達可能な変数を回収できない。結果として、Fiberが破棄されない限り、そのスタックに連なる全オブジェクトがリークする。
スコープガードによる防御的実装
この事態を防ぐため、Haxeマクロおよびスコープガード構造を用いて、Fiberの実行終了（正常終了、例外、早期中断）時に必ず参照をアンバインドする設計が不可欠である。
package runtime.async;
import php.Throwable;
class FiberScope {
/
- 安全にFiberコンテキストを実行し、リソースリークを防ぐランナー
/
public static function runSafe
var fiber:NativeFiber = null;
fiber = new NativeFiber(() -> {
try {
var result:T = task();
onSuccess(result);
} catch (e:Throwable) {
onError(e);
} finally {
// クリティカル: スタックフレーム上の参照を明示的にクリアする
// Haxeコンパイラによる最適化で消されないようSyntax.codeで確実にnullを代入
Syntax.code(“/ cleanup / {0} = null;”, fiber);
}
});
fiber.start();
return fiber;
}
}
—
例外バブリングとスコープ破壊のトラップ
Fiber境界を越える例外伝播（Exception Bubbling）には、Haxeプログラマが最も踏み抜きやすい罠が存在する。
1. `zend_bailout` (Fatal Error) の不可逆性
PHPの`try … catch`（Haxeの`try … catch`）で捕捉できないFatal Error（メモリ制限超過 `Allowed memory size exhausted` や、未定義関数の実行など）が発生した場合、Zend Engineは`longjmp`を用いて一気にリクエストのトップレベルへ実行を巻き戻す（`zend_bailout`）。
Fiber内で`zend_bailout`が発火した場合、Cスタックの巻き戻しルーチン（スタックアンワインディング）は正常に機能しない。デストラクタ（`__destruct`）は呼ばれず、Haxe側で担保していたリソース解放処理はすべてバイパスされる。
2. 未補足例外によるFiberのゾンビ化
Fiberの内部で発生した例外がFiber内部でキャッチされず、外部へ漏洩した場合、そのFiberは即座に`TERMINATED`状態へと遷移する。
// 危険なアンチパターン
var fiber = new NativeFiber(() -> {
throw new haxe.Exception(“Fatal fault inside fiber”);
});
try {
fiber.start();
} catch (e:Dynamic) {
// start() の呼び出し元でキャッチできるが…
}
// ここで fiber.isTerminated() は true
// このFiberインスタンスに対して resume() を叩くと \FiberError が発生しプロセスがクラッシュする
Haxeレイヤで安全な非同期基盤を構築するには、下図のようにFiberの境界ですべての例外をHaxeの型付けされたResult型（`Outcome
package runtime.async;
import haxe.ds.Option;
enum FiberResult
Success(value:T);
Failure(error:Dynamic);
}
class SafeFiberRunner {
public static function execute
var fiber = new NativeFiber(() -> {
try {
var val = block();
NativeFiber.suspend(Success(val));
} catch (e:Dynamic) {
NativeFiber.suspend(Failure(e));
}
});
var res:FiberResult
return res;
}
}
—
本番運用のための低レイヤ・アーキテクチャ設計
PHP 8.1+ のFiberをバックエンドにしたHaxeの非同期ランタイムを実運用（High-Throughput API Gatewayやマイクロサービス基盤）に投入する場合、以下のアーキテクチャ原則を順守しなければならない。
1. Fiberの使い捨てとオブジェクトプーリングのトレードオフ
Fiberの初期化（`new NativeFiber(…)`）には、OSレベルの仮想メモリマッピングとVMスタックの割り当てが伴う。数百万リクエストを処理する環境では、Fiberの生成コスト自体がスループットのボトルネックとなる。
しかし、Fiber自体の再利用（プーリング）は推奨されない。PHPのFiberは一度終了（`TERMINATED`）すると再スタートできない仕様となっており、ユーザランドで永続ループを回すプール構造を作ると、Zend VMスタックのフラグメンテーションとメモリリークの危険性が跳ね上がる。スタックサイズを最適化（64KB〜128KB）した上で、Fiberはリクエスト駆動で短命（Short-lived）に破棄するのが最も安全である。
2. イベントループ・ドライバの選択
Haxeの非同期処理を極限まで加速させるには、同期ブロックをFiberで逃がしつつ、最下層で`libuv`等のI/O多重化機構を動かす必要がある。
// Haxeから見た理想的な非同期I/Oの実行フロー
class Application {
static function main() {
EventLoop.init(); // reactphp/event-loop または revolt/event-loop の初期化
FiberScope.runSafe(() -> {
var httpClient = new AsyncHttpClient();
// 下記の呼び出しはFiberをサスペンドし、epollがI/O完了を検知した瞬間にレジュームされる
// スレッドをブロックせず、完全に非同期で実行される
var responseA = httpClient.get(“https://api.internal/v1/user”).await();
var responseB = httpClient.get(“https://api.internal/v1/order”).await();
Sys.println(“Combined Result: ” + responseA.body + responseB.body);
},
(success) -> Sys.println(“Process Completed.”),
(error) -> Sys.println(“Process Failed: ” + error.getMessage()));
EventLoop.run(); // メインスレッドのイベントループを開始
}
}
—
結論
HaxeからPHP 8.1のFiberをターゲットにする開発は、高レベルな型推論と低レベルなCスタック制御が交差する極めてエキサイティングな領域である。
1. Haxeのインライン最適化・抽象型（`abstract`）を駆使して、余分なオーバーヘッドを一切排除したサスペンド/レジュームの仕組みを構築する。
2. Zend Engineのスタック分離を常に意識し、コンテキストスイッチに伴うCスタックとVMスタックの負荷を最小化する。
3. Fiber境界を跨ぐクロージャ参照を厳密に管理し、未完了のFiberが引き起こす不可視のメモリリークをスコープガードで封殺する。
この3点を掌握したとき、HaxeはPHPという実行環境の制約を完全に突破し、Node.jsやGoに匹敵する超高速かつ堅牢な非同期コンピューティングを、エレガントな静的型安全性の下で実現可能にする。