【入門編】Swoole/RoadRunnerにおけるWorkerプロセス内のJIT状態共有：プロセス間メモリ共有の限界とリスク – PHPコア・内部エンジンと高速化・並行処理の極意解析バイブル

2026.08.27

こんにちは。普段からPHPのパフォーマンス限界や、モダンな非同期・常駐型アプリケーションのアーキテクチャに向き合っていますか？

Node.jsやGoといった言語のバックグラウンドを持ち、「リクエストごとにプロセスが破棄されない常駐型PHP（SwooleやRoadRunner）」の設計に踏み込んだとき、多くの優秀なエンジニアが一度は奇妙な壁にぶつかります。

「なぜ、JITを有効にしているのに、あるワーカープロセスだけ挙動がおかしいのか？」
「JITが生成したネイティブコードは、マルチプロセス環境でどう扱われているのか？」

今回は、Zend VMの内部構造と、SwooleやRoadRunnerといった常駐型ランタイムがメモリ上で何をしているのかを、低レイヤの視点から紐解いていきましょう。ここを理解すると、PHPの裏側が驚くほど美しく見えてきますよ。

—

1. 伝統的なCGI/FPMと「常駐型」の決定的な違い

まず、従来のPHP-FPMモデルを思い出してください。FPMは「Shared-Nothing（共有するものなし）」の思想に基づいています。1つのHTTPリクエストが来ると、マスタープロセスがワーカープロセスをフォーク（あるいはアサイン）し、リクエストの終了と共にプロセス空間はきれいにクリーンアップされます。

Zend JIT（PHP 8.0で導入された機能）も、このFPMモデルの上では非常にシンプルに動きます。

  • PHPスクリプトが読み込まれる
  • Opcacheがバイトコード（オペコード）に変換する
  • JITがホットスポット（高頻度で実行されるコード）を検出し、プロセスごとのメモリ空間内でx86/x64のネイティブマシン語にコンパイルする

ここでは、JITが生成するネイティブコードは「そのプロセスだけの使い捨て」です。プロセスが死ねば、OSがメモリを回収します。

しかし、SwooleやRoadRunnerのような常駐型（Long-running）プロセスの世界では、この前提がガラリと変わります。

—

2. Swoole/RoadRunnerにおける「プレフォーク」とJITの罠

SwooleやRoadRunnerは、リクエストのたびにPHPの起動・コンパイルを行うオーバーヘッドを排除するため、あらかじめマスタープロセス側でPHPスクリプトを読み込み、メモリ上にOpcacheや関数テーブルを展開した状態で「ワーカープロセス」を複数フォーク（プレフォーク）します。

ここで、次のような疑問が湧きませんか？

> 「マスタープロセスが起動時にJITを有効にしてネイティブコードまで生成してしまえば、子プロセスはそのJITコードを共有（Copy-on-Write）して爆速で動くのではないか？」

結論から言いましょう。それは幻想であり、重大なリスクを孕んでいます。

Zend JITが生成するネイティブコードは、単純な読み取り専用の静的データではありません。プロファイルの蓄積、メガモーフィックな呼び出しの最適化、さらには脱最適化（Deoptimization）など、実行時の型情報の変化に応じてJITバッファ内のコードやメタデータは動的に書き換えられます。

プロセス間でのJITメモリ共有の構造的限界

Linuxの `fork()` は、メモリを `Copy-on-Write (CoW)` で効率的に共有します。Opcacheの共有メモリ（SHM: Shared Memory）領域にあるオペコードなどは、基本的には全ワーカー間で安全に共有されます。

しかし、JITコンパイラが吐き出すネイティブコードのバッファ管理や、それに付随するJITの内部ステートは、プロセスごとのヒープや専用の mmap 領域に存在します。

[Master Process]
├── Opcache Shared Memory (Opcode) —> 全ワーカーから参照可能（SHM）
└── JIT Buffer (Native Machine Code) -> 原則としてプロセス固有の空間へ展開
│
├── [Worker 1] ──独自のJIT実行・最適化（ここで動的に書き換えが発生）
└── [Worker 2] ──独自のJIT実行・最適化（ワーカー間で状態が乖離）

もし、フォークの「前」にJITが有効化され、中途半端にネイティブコードが生成されてしまった場合、その後に各ワーカーが独立してリクエストを処理し始めると、JITの統計情報（プロファイル情報）の更新によって各ワーカーのメモリ空間がバラバラに汚染（CoWによる実体化）されていきます。

—

3. 事故を防ぐための実務的アプローチ：JITと常駐化の正しい付き合い方

では、SwooleやRoadRunner環境でJITの恩恵を安全に受けるには、どう設定し、どうコードを書くべきでしょうか。

① JITのバッファサイズとオプティマイザの調整

常駐環境でJITを有効にする場合、php.iniの設定には細心の注意が必要です。特に `opcache.jit_buffer_size` の設計が重要になります。

[opcache]
zend_extension=opcache.so
opcache.enable=1
opcache.enable_cli=1
; Opcache自体のメモリを十分に確保する
opcache.memory_consumption=256
; JITバッファサイズ（常駐環境では大きすぎるとプロセスごとのメモリフットプリントを圧迫する）
opcache.jit_buffer_size=64M
; トラース生成モード（常駐環境では 1205 や 1235 がよく選ばれる）
opcache.jit=1205

ここでポイントなのは、「プレフォークのタイミングとJITのコンパイルタイミング」のズレです。
多くの常駐型フレームワークでは、スクリプトのブートストラップ時に重い処理が走ります。このブートストラップ時にJITが過剰に働き、意図しないネイティブコードがマスタープロセス側に生成された状態でフォークされると、メモリの共有効率（CoW）が著しく低下します。

② ワーカーのライフサイクルとメモリリーク・JITキャッシュ肥大化への対策

Swooleなどのワーカーは数万リクエストを処理し続けます。JITは実行頻度の高いコードを次々とネイティブ化しますが、動的なコード生成（eval多用や、リクエストごとに構造が変わるメタプログラミング）を行うコードベースでは、JITバッファがフラグメンテーションを起こしたり、メモリリーク的な挙動を引き起こしたりすることがあります。

これを防ぐため、実務の現場では以下の防衛策をとります。

  • 最大リクエスト数の制限（Max Requests）の設定:

Swooleの `$server->set([‘max_request’ => 10000])` などの設定を必ず入れ、一定リクエストを処理したらワーカーを安全に再起動させます。これにより、JITバッファの肥大化や予期せぬメモリ断片化をリセットします。

  • ウォームアップスクリプトの活用:

ブートストラップ時に主要なルートやユースケースをあらかじめ擬似実行（ダミーリクエストの流し込みなど）させ、JITに必要なネイティブコードを完全に生成しきった状態でワーカーを安定稼働させます。

—

4. コードで見る：常駐環境における安全な設計思想

例えば、RoadRunnerのWorkerループ内で、動的なコード生成や極端なポリモーフィズムを用いた処理を書くと、JITの脱最適化（Deoptimization）が頻発し、CPUキャッシュヒット率が下がります。

以下は、常駐環境のZend VM上で効率的にJITをヒットさせるための、クリーンで予測可能なコードスタイルの例です。

  • 型が安定した（Monomorphicな）クラス設計
  • JITコンパイラがネイティブコードへの最適化を行いやすくする典型例

    • /
    readonly class PriceCalculator
    {
    public function __construct(
    private float $taxRate
    ) {}

    /

    • ホットループに入るメソッドは、引数や戻り値の型を厳格に固定する。
    • これにより、Zend VMがガード（型チェック）を省略した高速なマシン語を生成できる。

    /
    public function calculate(float $basePrice): float
    {
    // 算術演算のみのシンプルなスコープは、JITの最大の好物です
    return $basePrice (1.0 + $this->taxRate);
    }
    }

    // RoadRunner等のWorkerループのイメージ
    use Nyholm\Psr7\Response;
    use Psr\Http\Message\ServerRequestInterface;

    // 起動時にインスタンスを固定化（シングルトン的アプローチ）
    $calculator = new PriceCalculator(0.10);

    while ($req = $worker->wait()) {
    try {
    // リクエストごとに重いインスタンス生成や動的コード生成を避けることで、
    // JITバッファの状態をクリーンかつ安定に保つ
    $price = (float) $req->getQueryParams()[‘price’] ?? 0.0;
    $total = $calculator->calculate($price);

    $worker->respond(new Response(200, [], json_encode([‘total’ => $total])));
    } \Throwable $e {
    $worker->getWorker()->error((string)$e);
    }
    }

    このコードがなぜZend JITと常駐環境に優しいのか？

    1. 型の揺らぎがない（Monomorphic）: `$calculator->calculate()` の引数と戻り値が厳格に `float` で固定されているため、JITは複雑な型ガード（Guard）コードを挿入する必要がなくなり、極めて効率的な機械語を吐き出せます。
    2. 不変性（Immutability）: `readonly` プロパティを使うことで、オブジェクトの状態が実行途中で変化しないことが保証され、Opcache/JIT側も安全な最適化を行えます。
    3. インスタンスの再利用: ループ内で余計なオブジェクト生成を行わないため、ヒープの断片化を防ぎ、結果としてJITが管理するメモリ空間も健全に保たれます。

    —

    5. まとめ

    PHPのJITコンパイラは、単体で動かす分には非常に強力な武器ですが、SwooleやRoadRunnerといった「プロセスを永続化するマルチプロセス・アーキテクチャ」と組み合わせる瞬間、その挙動は一気に複雑さを増します。

    • JITが生成するネイティブコードはプロセスごとに固有の動的領域を持つ。
    • プレフォーク環境では、不必要な動的コード生成や過度なメタプログラミングがJITの効率を落とし、メモリのCoW効率を悪化させる。
    • `max_request` によるプロセスの定期的リフレッシュや、型を完全に安定させたコード設計（Monomorphic design）が、常駐型PHPにおけるJIT性能を引き出すカギとなる。

    「PHPは遅い、あるいは常駐に向かない」というのは、もはや過去の神話です。しかし、FPMの常識のまま常駐型へ移行すると、今回解説したようなメモリやJITの深いレイヤで足元をすくわれます。

    ぜひ、このエンジン内部の挙動を脳内に描いた上で、あなたのアプリケーションの設計を見つめ直してみてください。見慣れたPHPのコードの裏側が、驚くほど美しく、そして猛烈なスピードで駆動していることに気づくはずです。

    スポンサーリンク
    " "
    タイトルとURLをコピーしました