【テクニカル・上級編】PHP 8.x JITの「Function JIT」と「Tracing JIT」の使い分けとパフォーマンス特性 – PHPコア・内部エンジンと高速化・並行処理の極意解析バイブル

PHP 8.x JITの深淵：Function JITとTracing JITの内部メカニズムと実戦的最適化

PHP 8の登場により、Zend EngineにJIT（Just-In-Time）コンパイラが統合されてから数年の月日が経った。しかし、未だに `opcache.jit_buffer_size` を適当なサイズで設定し、`opcache.jit` のモード値を検索の上位に出てきたコピペ記事の通りに設定して「速くなった気がする」と言っているエンジニアが多いのは嘆かわしいことだ。

Webシステムアーキテクトとして大規模トラフィックを捌くとき、JITは魔法の杖ではない。Zend VMの内部構造、オペコード（opcode）のライフサイクル、そしてCPUのキャッシュヒット率やレジスタ割り付けの物理的制約を理解していなければ、JITは単なるメモリの無駄遣いに終わり、最悪の場合はコンパイルオーバーヘッドによってスループットを低下させる。

本稿では、PHP 8.x系におけるJITの2大モードである 「Function JIT」 と 「Tracing JIT」 の決定的な違いを、Zend VMの低レイヤ挙動とメモリ配置の観点から丸裸にする。

—

1. Zend VMとJITコンパイラの基礎：なぜPHPにJITが必要なのか

通常、PHPのスクリプトは以下のライフサイクルをたどる。

1. Lexer / Parser: ソースコードが抽象構文木（AST）に変換される。
2. Compiler: ASTがZend VMの実行可能なオペコード（Opcode）配列にコンパイルされる。
3. Execution: Zend VMがスタックベースの仮想マシンとして、C言語で書かれた巨大な `switch` 文（またはシグレッド・スレッドによるディスパッチ）の中でオペコードを1つずつ解釈・実行する。

この「Zend VMのインタプリタ解釈ループ」こそが、CやRustのようなネイティブ言語と比較した際のパフォーマンスのボトルネックであった。各オペコードのディスパッチごとにCPUの分岐予測ミスやメモリフェッチが発生するからだ。

OPcacheのJITは、この「Zend VM上のオペコード」を、x86_64やARM64のネイティブマシン語（Machine Code）に直接変換し、CPUのCPUレジスタ上で直接実行させることで、インタプリタのオーバーヘッドを極限まで排除する。

ここで重要になるのが、「どの単位でネイティブコードに変換するか」という戦略であり、それが `opcache.jit_mode`（または `opcache.jit` の数値設定）で指定する Function JIT と Tracing JIT の選択である。

—

2. Function JIT と Tracing JIT の内部構造の差異

PHPのJIT設定（例：`opcache.jit=1205` や `1255`）における百の位の数値は、JITの戦略を決定する。

Function JIT (関数単位のJIT)

概念: Zend VMが関数単位（`zend_function`）でコンパイル対象としてマークした際、その関数全体のオペコードを丸ごとネイティブマシン語に変換する。
メモリ・コンパイルコスト: 関数内のすべての分岐（`if/else` やループ）が一括してネイティブコード化される。実行頻度の低いエラーハンドリングのコードパスなども機械語に変換されるため、JITバッファを消費しやすい。
適用領域: 数値演算、配列の大量走査、暗号化処理など、関数全体がホットスポットとなっている場合に極めて高い効果を発揮する。

Tracing JIT (トレース単位のJIT)

概念: LuaJITやHotSpot JVMの方式に強く影響を受けたアプローチ。最初は通常のZend VMインタプリタとして実行し、ループ（`for`, `while`）の実行回数や関数の呼び出し回数がしきい値を超えたとき、その時の実際の実行パス（トレース）をプロファイリングする。
最適化の精度: 実際に高頻度で通過した「熱いパス（Hot Trace）」のみをネイティブコード化する。例えば、`if (condition)` のうち、99%の確率で真になる分岐があれば、偽のパスはJITコンパイル対象から除外され、機械語のコードサイズが小さく保たれる。
メモリ効率: コードサイズが小さいため、CPUの命令キャッシュ（i-cache）のヒット率が向上する。

—

3. 内部メモリ空間とプロファイルに基づく判断基準

Zend EngineのJITバッファは、共有メモリ（SHM）上に確保される。
Function JITとTracing JITのどちらを選択すべきかは、対象とするアプリケーションの特性（CPU Bound vs I/O Bound）によって完全に分かれる。

ベンチマークとプロファイリングによる判断基準

以下のPHPコードは、典型的なCPUバウンドな数値演算（Mandelbrot集合の計算や素数判定など）のモックである。

0) {
$result += $x 1.5;
} else {
$result -= $x 0.5;
}
}
return $result;
}

// 実際のWebリクエストを模擬したルーティング・I/Oバウンドな処理
function handle_web_request(array $payload): array {
$data = json_encode($payload);
// 擬似的なバリデーションや配列操作
$decoded = json_decode($data, true);
$output = [];
foreach ($decoded as $key => $value) {
$output[strtoupper($key)] = htmlspecialchars((string)$value, ENT_QUOTES, ‘UTF-8’);
}
return $output;
}

1. 数値演算・アルゴリズム処理（`heavy_numeric_crunching`）の場合

有利なモード: Function JIT
理由: ループ内の命令数が予測可能であり、関数全体がホットスポットとなるため、プロファイリングのオーバーヘッド（ガードの挿入やトレース記録のコスト）を払うよりも、関数全体を最初からマシン語に落とし込んだ方がスループットが向上する。
推奨設定（php.ini）:

opcache.jit_buffer_size=128M
opcache.jit=1205
; 1: 関数JIT有効, 2: ログ出力無効, 0: 既存の最適化, 5: 全関数を対象にコンパイル

2. 標準的なWebアプリケーション・フレームワーク（Laravel/Symfony等）のライフサイクル（`handle_web_request`）の場合

有利なモード: Tracing JIT
理由: フレームワークのコードベースは巨大であり、リクエストごとに実行されるコードパスは全体のわずか数パーセント（ルーティング、特定のミドルウェア、ORMのクエリ構築）に過ぎない。Function JITを適用すると、ほとんど実行されないコントローラーやライブラリのメソッドまでJITバッファを圧迫し、i-cacheのミスヒットを引き起こす。Tracing JITであれば、頻繁に実行されるホットなループやメソッドの内部パスのみがピンポイントで最適化される。
推奨設定（php.ini）:

opcache.jit_buffer_size=128M
opcache.jit=1255
; 1: トレースJIT有効, 2: プロファイル情報に基づくトレース, 5: 高度な最適化パス

—

4. OPcacheプリローディングとの物理的関係

JITを真に活かすためには、`opcache.preload` によるプリローディング（事前読み込み）が不可欠である。

PHPのFPMプロセスが起動する際、親プロセス（Master Process）のメモリ空間にあらかじめアプリケーションの全クラス・関数ファイルを読み込ませ、ASTからオペコードへのコンパイルを完了させておく。
さらに、JITが有効な環境下では、プリロード時に関数単位のJITコンパイルを事前に実行しておくこと（JITコンパイル済みのマシン語を親プロセスの共有メモリに配置）が可能になる。

これにより、子プロセス（Worker Process）がフォーク（`fork()`）された瞬間から、すべてのワーカーがJIT済みのネイティブマシン語を共有メモリ経由でそのまま利用できるため、コールドスタート時のレイテンシ（最初の数リクエストでJITが走ることによるカクつき）を完全に排除できる。

—

5. セキュリティとJITの深淵：W^X（Write XOR Execute）の壁

低レイヤのシステム設計において避けて通れないのがセキュリティ、特にメモリ保護機構である。

現代のOS（Linux等）およびCPUは、セキュリティ上の厳格な鉄則として W^X（Write XOR Execute） を強制している。つまり、「メモリ領域は書き込み可能（W）であるか、あるいは実行可能（X）であるか、どちらか一方でなければならない」。悪意ある攻撃者がスタックやヒープにシェルコードを書き込み、そこを実行へ移す（コードインジェクションやPHPオブジェクトインジェクションからのgadget chain実行）のを防ぐためだ。

JITコンパイラはこのセキュリティ原則の最大の例外、あるいは「合法的な突破者」である。JITは実行時に動的に機械語コードをメモリに書き込み（Write）、その後そのメモリ領域にジャンプして実行（Execute）しなければならない。

PHPのJITエンジンは、内部的に `mmap` や `mprotect` システムコールを駆使し、JITバッファのメモリ属性を以下のように動的に切り替えている。

1. コード生成時: メモリ領域を `PROT_WRITE | PROT_READ` に設定し、機械語（アセンブリ）のバイト列を書き込む。
2. 実行時: メモリ領域を `PROT_READ | PROT_EXEC` に変更し、書き込み権限を剥奪した上でCPUのプログラムカウンタをそこに飛ばす。

もしPHPの脆弱性（例：深刻なメモリ破損バグや不適切な拡張モジュールの挙動）によって、このJITバッファの書き込み・実行権限の切り替えロジックがハッキングされれば、攻撃者は任意のネイティブコードをJITバッファ経由で直接実行する足がかり（JIT Spraying）を得てしまう。Webアーキテクトとして、JITを有効化するということは、CPU性能と引き換えに、わずかながら攻撃サーフェス（アタックサーフェス）を広げているという事実を直視しなければならない。

—

結びにかえて

PHP 8.xのJITは、単なる「速くなるスイッチ」ではない。
CPUのパイプライン、キャッシュ階層（L1i/L1d, L2, L3）、OSのメモリ管理（`mprotect`）、そしてZend VMのオペコード構造のすべてを理解した者だけが、その真のパフォーマンスを引き出すことができる。

アプリケーションの特性を見極めよ。CPUバウンドな数値計算には Function JIT を、巨大なコードベースを持つWebアプリケーションには Tracing JIT を。そして、OPcacheプリローディングと組み合わせることで、PHPはインタプリタの枠を超えた真の高速実行エンジンへと昇華する。

限界を突破せよ。コードの深淵には、常に最適解が眠っている。