こんにちは。普段は大規模なWebシステムのアーキテクチャ設計や、PHPのコアエンジンのチューニングに明け暮れています。
JavaやGo、あるいはNode.jsといった他言語の深い経験を持つ優秀なエンジニアほど、PHPの「1リクエストごとにプロセスが破棄される手軽さ」から一歩踏み出し、巨大なモノリスや高スループットなAPIをPHPで構築しようとした壁にぶつかりがちです。「なぜ、メモリ消費量が増え続けるのか」「JITを有効にしたのに、期待したほどCPUバウンドな処理が速くならないのはなぜか」。
今回は、PHP 8.xの心臓部であるJIT（Just-In-Time）コンパイラの最適化レベルと、それが生み出すメモリ使用量・実行速度のトレードオフについて、Zendエンジンの内部挙動まで踏み込んで紐解いていきます。ここを理解すれば、PHPの裏側が驚くほどクリアに見えるようになりますよ。
—
1. PHP 8.x JITとZend VMのランタイム挙動
私たちが書いたPHPコードは、パーサによって抽象構文木（AST）に変換され、最終的にZend VMが解釈・実行するためのオペコード（Opcode）へとコンパイルされます。
通常、PHPはこのオペコードをZend VMの評価ループ（巨大な`switch`文の塊であるC言語のコード）で1つずつ解釈実行します。これがいわゆるインタープリタとしての挙動ですね。しかし、PHP 8で導入されたJITは、このオペコードの一部、あるいは大部分を、CPUが直接実行できるネイティブマシン語（x86/ARM機械語）にコンパイルし、メモリ上の実行可能領域に配置します。
ここで重要になるのが、JITが生成するネイティブコードがどこに置かれ、どれだけのメモリを消費するかという点です。
JITの2つのモード：Tracer vs Function
PHP 8のJITには、主に2つのアプローチ（`opcache.jit_buffer_size`の設定と関連）があります。
- Function JIT: 関数単位でネイティブコードにコンパイルします。実装はシンプルですが、実行頻度の低いコードパスも丸ごと機械語になるため、メモリ効率が悪化しがちです。
- Tracer JIT: 実際の実行トレース（ループ構造など）をプロファイルし、ホットスポット（最も実行されているパス）だけをネイティブコード化します。PHP 8のデフォルトであり、実用上最も洗練されています。
—
2. JIT最適化レベル（`opcache.jit`）の正体
`php.ini`における `opcache.jit` の設定は、4桁の整数（例: `1255` や `1235`）で細かく制御されます。この数字の意味を、エンジンの最適化パスの観点から分解してみましょう。
; php.ini の設定例（Tracer JITを有効化し、アグレッシブな最適化を行う場合）
opcache.enable = 1
opcache.jit_buffer_size = 100M
opcache.jit = 1255
この `1255` という値は、左から順に以下のフラグやレベルを表しています。
1. CPU特化の最適化フラグ
2. 登録/レジスタ割り当ての戦略
3. グローバル最適化のレベル（0〜3）
4. JITトリガーのタイミングと生成戦略（0〜5）
特に注目すべきは、グローバル最適化レベルとJITトリガー戦略です。最適化レベルを上げると、コンパイラは型推論をより厳密に行い、冗長なZendの内部関数呼び出しをインライン展開したり、不要なメモリ確保（zvalのboxing/unboxing）を削ぎ落としたりします。
最適化を上げるほど「メモリ」と「ビルド時間」のコストが跳ね上がる
しかし、ここにトレードオフがあります。
最適化レベルを引き上げる（例えばレベル3にする）と、Zendエンジンはコードの静的解析により多くのCPUサイクルを費やします。さらに、生成されるネイティブコードのサイズ（バイナリのフットプリント）が肥大化します。
想像してみてください。`opcache.jit_buffer_size` に割り当てたメモリプール（デフォルトでは控えめなサイズ、あるいは数テンメガバイト）が、過剰に最適化された巨大なネイティブコードで瞬く間に満杯になってしまったらどうなるでしょうか。バッファがあふれると、JITは新規のコードをコンパイルできなくなり、最悪の場合はキャッシュのフラッシュやフォールバックが発生し、かえってパフォーマンスが劣化する「JITスラッシング」を引き起こします。
—
3. 実践：プロファイリングによる「スイートスポット」の見つけ方
では、私たちのアプリケーションにとって「最適なJITレベル」はどう見つければよいのでしょうか。勘やネットのコピペに頼る必要はありません。正確なプロファイリングを行いましょう。
ここでは、CPUバウンドな配列処理とオブジェクト生成が混在するコードを例に、メモリと速度のバランスを検証するシチュエーションを考えてみます。
/
class MatrixProcessor {
private array $matrix;
public function __construct(int $size) {
// 大量のプリミティブデータを保持するHashTableの構築
for ($i = 0; $i < $size; $i++) {
$this->matrix[$i] = range(0, $size);
}
}
public function compute(): int {
$sum = 0;
foreach ($this->matrix as $row) {
foreach ($row as $val) {
// 型の揺れがない純粋な算術演算（JITの好物）
$sum += ($val 3) % 7;
}
}
return $sum;
}
}
$startMemory = memory_get_usage(true);
$startTime = microtime(true);
$processor = new MatrixProcessor(500);
$result = $processor->compute();
$endTime = microtime(true);
$endMemory = memory_get_usage(true);
echo “計算結果: {$result}\n”;
echo “実行時間: ” . round(($endTime – $startTime) 1000, 2) . ” ms\n”;
echo “メモリ使用量差分: ” . round(($endMemory – $startMemory) / 1024 / 1024, 2) . ” MB\n”;
チューニングのステップ
1. ベースラインの測定（JIT無効）
まずは `opcache.jit = 0` で実行し、実行時間とメモリ消費量を記録します。
2. 標準的なTracer JITの適用（`opcache.jit = 1255`）
デフォルトの強力な最適化を試します。多くの場合、ここでCPUバウンドな処理の実行時間が劇的に短縮されます。
3. JITバッファ使用状況の監視
`opcache_get_status()` を使い、JITバッファがどれくらい消費されているかをスクリプトから、あるいはCLIで確認します。
「最適化レベルが高すぎて、ネイティブコードが大きくなりすぎている」か、あるいは「`opcache.jit_buffer_size` の割り当てが小さすぎる」サインです。
大規模なWebアプリケーション（SymfonyやLaravelなどのフルスタックフレームワーク）では、コードベースが数万ファイルに及びます。すべてのコードが頻繁に実行されるわけではないため、あまりにアグレッシブな最適化や、不適切なバッファサイズ設定は、かえってOPcacheのメモリ管理を圧迫し、FPMプロセスのフットプリントを膨らませる原因になります。
—
4. アーキテクトとしての結論：どう設定すべきか
実務の現場において、私は次のような方針でJITと向き合うことを推奨しています。
- I/Oバウンドな一般的なWebアプリケーション（CRUD中心）:
JITによる恩恵は限定的です。デフォルトのままでも良いですが、バッファサイズを過大に取る必要はありません（32M〜64M程度で十分なことが多いです）。メモリを圧迫しないよう、無理にアグレッシブなレベル（レベル4や5）を追う必要はありません。
- AI/ML処理、暗号化、画像処理、巨大な配列計算をPHPで行う場合（CPUバウンド）:
`opcache.jit = 1255` をベースにしつつ、負荷テストツール（wrkやk6など）でスループットを計測してください。その際、必ず `opcache_get_status()` でJITバッファの溢れがないかを監視します。バッファが足りないなら `100M` 以上に拡張し、ネイティブコードがキャッシュミスを起こさない環境を整えます。
PHPは単なる「お手軽なスクリプト言語」から、JITを得たことで「高パフォーマンスなモダンランタイム」へと進化しました。その裏側にあるメモリとCPUのトレードオフを正しく理解し、プロファイルに基づいた冷静なチューニングを行えば、あなたのアプリケーションは見違えるほどの速度と安定性を手に入れるはずです。
裏側を知ることで、PHPコーディングはもっと楽しく、もっと深いものになります。ぜひ、ご自身の環境でも試してみてくださいね。