こんにちは！PHPの深層へようこそ。
JavaやGo、C#といった言語で低レイヤの最適化を経験してきたエンジニアの皆さんが、モダンなPHP（PHP 8.x）のコードを触ったとき、あるいはPerformance Bottleneckの調査に入ったとき、一度は疑問に思ったことがあるのではないでしょうか。
「PHP 8で導入されたJIT（Just-In-Time）コンパイラって、実際のところ内部で何をしているんだろう？」
「スクリプト言語であるPHPが、どうやってZend VMの実行ループを跳び越えて、ネイティブコードをCPUに直接叩き込んでいるのか？」
一般的なWebアプリケーションの開発では、DBアクセスや外部API呼び出しといったI/Oバウンドな処理が支配的であるため、JITの恩恵が見えにくい場面もあります。しかし、内部エンジンの挙動、特にオペコード（Opcode）の生成からZend VM実行パスのバイパス、そしてCPUレジスタレベルでの命令実行への変遷を正しく理解しておくと、PHPがどのようにメモリ空間（`zval`）を扱い、CPUの演算リソースを限界まで引き出そうとしているのか、その「美しさ」が鮮明に見えてくるはずです。
今回は、PHP 8.xのJITコンパイラがオペコードをネイティブマシン語へと変換し、Zend VMのオーバーヘッドを極限まで削ぎ落とすメカニズムを、エンジン内部の構造体や実行パスに踏み込んで紐解いていきましょう。ここを理解すれば、PHPの裏側が綺麗に見えますよ。
—
1. Zend VMの伝統的な実行パス：オペコードとディスパッチループ
JITの革新性を理解するために、まずはPHP 7時代までの標準的な実行メカニズム（Zend VM）をおさらいしておきましょう。
PHPスクリプトがWebリクエスト（PHP-FPMなど）を受けて実行される際、Zend Engineは以下のパイプラインを辿ります。
[PHPソースコード]
│
▼ (Lexical Analysis & Parsing)
[抽象構文木 (AST)]
│
▼ (Compilation)
[オペコード配列 (zend_op_array)] <-- OPcacheが共有メモリ(SHM)にキャッシュする領域
│
▼ (Execution)
[Zend VM 実行ループ (zend_execute)]
オペコード配列（`zend_op_array`）とは何か
コンパイラ段階で生成されるのは、C言語の構造体 `zend_op` の配列です。各オペコードは、1つの命令（例: `ZEND_ADD`, `ZEND_ASSIGN`, `ZEND_RETURN` など）を表します。
簡略化した `zend_op` 構造体のイメージは次の通りです。
// Zend Engine内部の zend_op 構造体概念（C言語レベル）
struct _zend_op {
const void handler; // 実行すべきVMハンドラ関数へのポインタ
znode_op op1; // オペランド1（変数や定数へのオフセット）
znode_op op2; // オペランド2
znode_op result; // 演算結果の格納先
uint32_t extended_value;
uint32_t lineno; // 行番号
zend_uchar opcode; // 命令コード（例: 1 = ZEND_ADD）
/ … /
};
VMディスパッチループの「重み」
Zend VMは、仮想的なCPUとして動作する「ソフトウェアベースのインタープリタ」です。デフォルトでは HYBRID または CALL / SWITCH 方式のディスパッチテーブルを用いて、`zend_op_array` 内の命令を1つずつ順番に実行します。
// Zend VMのディスパッチループの概念イメージ
void zend_execute(zend_op_array op_array, zval return_value) {
zend_execute_data execute_data = zend_vm_stack_push(…);
while (1) {
// 1. 現在のオペコードを取得
zend_op opline = execute_data->opline;
// 2. 命令に対応するC言語のハンドラ関数を呼び出す（間接ジャンプ/関数呼び出し）
opline->handler(execute_data);
// 3. 次のオペコードへポインタを進める
execute_data->opline++;
// 終了条件チェック等…
}
}
このインタープリタ方式には、明確なCPUレベルのオーバーヘッドが存在します。
1. VM Fetch / Dispatch Overhead: 次の `zend_op` を取り出し、ハンドラへ分岐するためのCPUBranch Prediction（分岐予測）ミスとL1d/L1iキャッシュミス。
2. `zval` の型チェック: PHPは動的型付け言語です。例えば `ZEND_ADD` ハンドラ内部では、実行されるたびに `op1` と `op2` が整数（`IS_LONG`）なのか、浮動小数点（`IS_DOUBLE`）なのか、文字列なのかを判定するC言語の `switch` 分岐が走ります。
3. メモリ経由のデータ渡し: 演算結果は常にスタック上の `zval`（16バイトの汎用値構造体）に書き戻され、CPUレジスタを効率的に使い回すことができません。
この「毎回型を確認し、`zval` 構造体を開封し、計算して、`zval` に包み直す」というループのオーバーヘッドを打破するのが、PHP 8.xの JIT（Just-In-Time）コンパイラ です。
—
2. PHP 8.x JITの核心：Tracing JITとオペコード変換
PHP 8.xには Function JIT と Tracing JIT の2種類が実装されていますが、本命は断然 Tracing JIT です。
通常のJIT（Java HotSpotなど）が「関数単位」でネイティブコード化を検討するのに対し、Tracing JITは「頻繁に実行される実行パス（ホットなループ）」を実行時のトレース情報を元に特定し、その一本の直線的なコードパスだけをターゲットにマシン語へコンパイルします。
[ Zend VM でオペコードを実行 ]
│ (プロファイリング: カウンタ加算)
▼
【ホットスポット（ループ）検出】
│
▼
[ トレースの記録 (Tracing) ]
実行中の型情報 (例: $i は常に integer) を記録しながら
オペコード列をキャプチャする
│
▼
[ IR (中間表現) への変換 ]
PHP固有の複雑な命令を、低レベルなIR命令列へ最適化・簡略化
│
▼
[ DynASM によるマシン語生成 ]
x86-64 / AArch64 のネイティブバイナリをRAM上に直接生成
│
▼
【 JITコード（RAM上）を実行 】
Zend VM ループをバイパスしてCPUが直接演算！
IR（中間表現）への最適化と型推論（Type Specialization）
Tracing JITの最も強力なポイントは、「動的型付けの仮面を剥がす」 ことにあります。
例えば、以下のような典型的なループ処理を考えてみましょう。
「このループ内において `$sum` と `$i` は100% `IS_LONG`（整数）である」 という事実を記録します。
この情報をもとに、JITコンパイラは `ZEND_ADD` をC言語の関数呼び出しではなく、CPUの単一の加算命令（例: `add rbx, rax`） へと変換するIRを組み立てます。
—
3. VMバイパスの真実：`zval` 解体とレジスタ割り当て
JITコンパイラが実現する最大の高速化、それが 「Zend VMのバイパス」 と 「`zval` の解体（Unboxing）」 です。
従来の `zval` アクセス vs JITのCPUレジスタ直接保持
PHPの変数はすべて `zval` 構造体（16バイト）としてメモリ（Zend VM Stack）上に配置されます。
// zval 構造体の概念（16バイト）
struct _zval_struct {
zend_value value; // 8バイトの共用体 (long, double, zend_string など)
union {
uint32_t type_info; // 型情報 (IS_LONG, IS_DOUBLE, IS_STRING など)
/ … /
} u1;
/ … /
};
Zend VMで `$sum += $i` を計算する場合、以下のようにメモリを反復して読み書きします。
1. `$sum` の `zval` から `u1.type_info` を読み取り、整数かチェック。
2. `$i` の `zval` から `u1.type_info` を読み取り、整数かチェック。
3. それぞれの `value.lval`（8バイトの整数値）をCPUレジスタにロードして加算。
4. 結果を `$sum` の `zval.value.lval` に書き戻し、型情報も更新。
一方、JITコンパイルされた領域では、`zval` という概念そのものが消滅 します。
JITは、CPUの物理レジスタ（x86-64なら `RAX`, `RBX`, `RCX`, `R12` など）に `$sum` と `$i` の生データ（64ビット整数値）を直接割り当てます（Register Allocation）。16バイトの構造体読み書きやメモリバスへのアクセスは一切発生せず、CPUのL1キャッシュすら超えた超高速なレジスタ間演算のみでループが回転するのです。
ガード（Guard）とサイドエグジット（Side Exit）：安全なVMへの復帰メカニズム
「型チェックを省いてネイティブコードを実行するなら、万が一型が変わったらどうするのか？」と疑問に思いますよね。ここで登場するのが Guard（保護判定） と Side Exit（退避処理） です。
JITが生成したネイティブコードの先頭には、非常に軽量な「ガード命令」が挿入されます。
; JITが生成するネイティブコードの概念（x86-64アセンブリイメージ）
; RDI に iterations の zval ポインタが入っていると仮定
cmp dword ptr [rdi + 8], 4 ; Guard: iterations の type_info が IS_LONG (4) か？
jne .side_exit_1 ; 型が違えば即座に Side Exit へジャンプ！
; Guardを通過！ここからは純粋な高速レジスタ演算
mov rax, 0 ; rax ($sum) = 0
mov rbx, 0 ; rbx ($i) = 0
mov r12, qword ptr [rdi] ; r12 = iterations の生の値 (long)
.loop_start:
cmp rbx, r12 ; $i < $iterations
jge .loop_end
add rax, rbx ; $sum += $i (超高速！1クロックサイクル)
inc rbx ; $i++
jmp .loop_start
.loop_end:
; ループ終了後、結果を zval 形式に包み直して Zend VM のスタックに書き戻す
...
ret
.side_exit_1:
; 型の前提が崩れた！JIT処理を中断し、現在の状態を zval に復元して Zend VM に制御を戻す
call BailoutToZendVM
このガード機構があるおかげで、PHPは「普段は動的型付け言語として自由にコードを書きつつ、ホットスポットだけはC言語やRustと同等の静的型ネイティブコードとして実行する」という二面性を安全に両立できるのです。
---
4. 【実証とコード検証】JITの挙動を脳内トレースする
では、実際にJITが有効化された際に、内部でどのようなオペコードが生成され、どのように最適化されるのかを意識できる実験コードを見てみましょう。
以下のコードは、大量の浮動小数点演算とループ処理を行うPHPスクリプトです。
/
declare(strict_types=1);
function benchMatrixCalculation(int $size): float
{
$result = 0.0;
// JIT Tracing がこの二重ループをホットスポットとして検知する
for ($i = 0; $i < $size; $i++) {
for ($j = 0; $j < $size; $j++) {
// 浮動小数点 (IS_DOUBLE) の積算処理
// JIT未適用: ZEND_MULTIPLY と ZEND_ADD_LONG が毎回 zval を解体
// JIT適用済: CPUの SSE2/AVX レジスタ (XMM0, XMM1) を使った mulsd / addsd 命令に直接変換
$result += ($i 0.001) ($j 0.002);
}
}
return $result;
}
$startTime = microtime(true);
$res = benchMatrixCalculation(3000);
$executionTime = microtime(true) - $startTime;
printf("Result: %f\n", $res);
printf("Execution Time: %.4f seconds\n", $executionTime);
オペコード変換とJIT命令のトレース比較
このコードが実行される際、Zend VMのオペコードレベルとJITのネイティブコードレベルでは、処理の重みが劇的に変化します。
【Zend VMのみ（JIT OFF）の実行パス】
1. `ZEND_FETCH_DIM_R` や `ZEND_ASSIGN` などの各ステップで、`zend_execute_data` ポインタの更新が発生。
2. `$i 0.001` の実行時に `ZEND_MUL` ハンドラが呼ばれ、C言語の関数呼び出し（CALL）オーバーヘッドが発生。
3. 演算のたびに `zval` の型フラグを比較し、メモリ上のスタックフレームに格納。
【Tracing JIT適用（JIT ON）の実行パス】
1. ホットスポット検出: 内側のループが一定回数（デフォルトで数千回）実行された段階でトレースが開始される。
2. 型固定の確定: `$i`, `$j`, `$result` がすべて `double`（浮動小数点数）または `long`（整数）であることを検出。
3. VMバイパス: 内側ループ全体の `zend_op` 列が消滅。
4. AVX/SSEレジスタ命令化:
- `mulsd xmm0, xmm1`（CPUの浮動小数点乗算命令）
- `addsd xmm2, xmm0`（CPUの浮動小数点加算命令）
5. ループのネイティブ化: レジスタの比較 `cmp` と 近接ジャンプ `jne` のみでループが回るため、Zend VMのループ構造への復帰すら一切行われない。
—
5. Webアーキテクチャ視点でのJITの使い所と限界
ここまでJITの凄烈な仕組みを見てきましたが、世界最高峰のアーキテクチャ設計を目指す上では、「どこで効いて、どこで効かないのか」 を冷徹に見極める必要があります。
I/OバウンドなWebアプリケーションでの現実
一般的なWebアプリケーション（LaravelやSymfonyを用いたCRUD系APIなど）のボトルネックは、どこにあるでしょうか？
- PostgreSQLやMySQLからのレスポンス待ち（ネットワークI/O）
- RedisやMemcachedとのやり取り（ネットワークI/O）
- ディスクからのテンプレートファイル読み込みやログ出力（ファイルI/O）
- JSONのエンコード・デコード
これらの処理は I/Oバウンド です。CPUがオペコードをぶん回している時間よりも、外部システムからの応答を待っている時間の方が遥かに長いため、JITによってCPU演算速度が10倍になっても、全体のレスポンスタイムの改善率は数%にとどまることがあります。
JITが「爆発的な威力」を発揮する領域
しかし、以下のようなドメインやコンポーネントでは、JITは圧倒的な破壊力をもたらします。
1. CPUバウンドな算術・解析処理
- 画像処理・音声処理（例: GDやPure PHPによる画像リサイズ、波形解析）
- 複雑な暗号化・復号アルゴリズム、ハッシュ計算
- 機械学習の推論ロジックや統計計算（Pure PHP実装）
2. 長時間のCLIプロセッシング・ワーカー
- SwooleやWorkerman、RoadRunner上で動作する常駐型PHP常駐プロセス
- 大規模なデータインポート・ETLパイプライン（ASTパースや正規表現解析の多用）
3. テンプレートエンジンのコンパイルフェーズ
- 大量の文字列解析や構文木構築をPHP上で行うライブラリ
—
6. まとめ：PHPの内部構造を理解した先にあるもの
PHP 8.xのJITコンパイラは、単なる「速度向上のための魔法」ではありません。
その本質は、「動的言語としての柔軟性を保つZend VM」と「静的言語並みの極限性能を叩き出すCPU直結のネイティブコード」を、プロファイリングとGuard機構によってシームレスに行き来する極めて美しいアーキテクチャ にあります。
- Zend VM は、コードの柔軟性を保証し、動的な型変更やデバッグ、例外処理を支える安全網。
- Tracing JIT は、確定した型情報を元に `zval` を解体し、CPUレジスタとアセンブリ命令の領域へコードを叩き落とすエンジン。
この仕組みを頭の中に描けるようになると、普段書いているPHPコードの1行1行が、Zend Engine内部でどのように `zval` に割り当てられ、どのタイミングでJITのトレース対象になり、メモリやCPUキャッシュをどう通過しているのかが手に取るように見えてきます。
フレームワークの枠組みを超えて、実行エンジンのレイヤからシステムの最適化を語れるアーキテクチャを目指していきましょう。PHPの裏側は、知れば知るほど本当に面白いですよ！