こんにちは。PHPの裏側で動いているZend VMの鼓動や、メモリの息吹を感じたことはありますか？
普段私たちが何気なく書いているPHPコードは、実はインタプリタとしてそのまま実行されているわけではありません。レクサ（Lexer）とパーサ（Parser）によって抽象構文木（AST）に変換され、最終的にZend Executorが解釈する「オペコード（Opcode）」へとコンパイルされます。そしてPHP 8以降の世界では、このオペコードをさらにネイティブの機械語（マシン語）へとダイレクトに変換するJIT（Just-In-Time）コンパイラが、パフォーマンスの限界を押し上げています。
他の言語（JavaやC#など）でJITの恩恵を受けてきた方なら、「PHPのJITって、いったい中で何をやっているんだろう？」「特定の重い処理だけをピンポイントでJITに最適化させたい、あるいは変なバグを踏むから特定のコードはJITから外したい」と思ったことがあるのではないでしょうか。
今回は、PHP 8.x系におけるJITコンパイラの内部構造、特に「トレーシングJIT」のメカニズムと、それを制御するための最適化パス・除外ルールの裏側を、優しく紐解いていきましょう。ここを理解すると、PHPという言語の見え方がガラリと変わりますよ。
—
1. PHP 8 JITの心臓部：「トレーシングJIT」の正体
PHP 8で導入されたJIT（DynASMベース）には、関数単位でネイティブ化する「Function JIT」と、ループの実行頻度を監視してホットスポットをネイティブ化する「Trace JIT」の2つのモードがあります。標準的によく使われるのは後者のトレーシングJITです。
Zend VMの内部では、スクリプトの実行中に「どのループが何回実行されたか」を常にプロファイリングしています。
[PHPコード]
↓ (コンパイル)
[オペコード (Opcodes)]
↓ (実行時プロファイリング)
[ホットループ検出] ──> [トレース記録 (IR生成)] ──> [JITコンパイラ (機械語生成)]
ある一定の閾値を超えて頻繁に実行されるループ（ホットスポット）に到達すると、Zend VMはそれを「トレース」として記録します。このトレースされた一連のオペコード列が、中間表現（IR: Intermediate Representation）に変換され、最終的にCPUが直接理解できる機械語へとコンパイルされるわけです。
しかし、ここでエンジニアとして知っておくべき現実があります。すべてのコードをJITにかければ速くなるわけではないということです。メタプログラミングを多用する複雑なコードや、動的な型が激しく変わる領域では、JITが逆にオーバーヘッドになり、CPUキャッシュを無駄に消費してしまう「JITの罠」が存在します。
—
2. なぜ最適化パスの制御や除外が必要なのか？
大規模なWebアプリケーションやドメイン駆動設計（DDD）を採用したモダンなフレームワークでは、無数の小さなメソッドやオブジェクトのラップが連鎖します。
Zend VMのメモリ空間上では、これらは細かなHashTableのルックアップと関数呼び出しの連続になります。JITはこれらをインライン展開しようと試みますが、コードのパスが複雑すぎると、JITコンパイラ自身が最適化の迷宮に迷い込み、コンパイルに時間を奪われたり、かえって非効率な機械語を生み出したりします。
だからこそ、「どの処理をJITの対象とし、どの処理をあえて除外するか」をアーキテクトの意図通りにコントロールする知見が重要になってくるのです。
—
3. 実践：JITの挙動制御とコードレベルでのアプローチ
PHP公式の `php.ini` 設定である `opcache.jit` の数値（例: `1235` や `1255` など）を調整することで、JITの挙動（FunctionかTraceか、CPUの登録レジスタの割り当て方針など）を大雑把にコントロールできます。
しかし、より現場で求められるのは、「特定のビジネスロジックや、JITと相性の悪い動的評価を行うコード領域を、安全にJITの最適化パスから外す（あるいは安全に処理させる）」という設計手法です。
ここでは、Zend VMの挙動を意識しつつ、JITフレンドリーなコードと、あえて最適化の暴走を防ぐための設計アプローチを見てみましょう。
例：動的コールや極端な型揺れを避け、JITの恩恵を最大化する構造
JITコンパイラは「型が予測可能（Monomorphic）」な状態で最も強さを発揮します。逆に、1つの変数に整数、文字列、オブジェクトが代入され続けるようなコード（Polymorphic）は、JITにとって悪夢です。
/
class MathProcessor
{
public function calculateStrict(int $a, int $b): int
{
$accumulator = 0;
// このような単純かつ高頻度に回るホットループは、
// トレーシングJITの絶好のターゲットとなり、ネイティブのCPU命令に置き換わります。
for ($i = 0; $i < 100000; $i++) {
$accumulator += ($a $b) + $i;
}
return $accumulator;
}
}
このコードは、引数および内部の変数の型が完全に `int` で固定されています。JITはこの部分のIR（中間表現）を非常にシンプルに構築でき、CPUのレジスタ上に変数を保持したまま高速な演算ループを回すことができます。
では、JITの最適化を「あえてバイパス・除外」したいときは？
例えば、リフレクションを多用するDIコンテナの初期化処理や、実行時になわばりを変えるような極端な動的コードの領域では、JITが無理な最適化を試みてコンパイルパニック（あるいはメモリ効率の悪化）を起こすことがあります。
直接的に「この行だけJITをオフにする」という構文（例: `#[\NoJit]` のような属性）は、現在の標準PHPコアには存在しません（※OPcacheのバッファや関数単位での除外は `php.ini` の設定や拡張機能レベルで行う必要があります）。
そのため、実務的なアーキテクチャ設計としては、「JITが効率的に処理できるホットスポット（数値演算やデータ処理）」と「動的でJITの恩恵を受けにくい領域（メタプログラミングやI/O）」を、明確にクラスやファイル単位で分離することが最も洗練されたアプローチになります。
/
class DynamicDispatcher
{
private array $registry = [];
public function register(string $name, callable $resolver): void
{
// 実行時バインディングが頻発する領域
$this->registry[$name] = $resolver;
}
public function dispatch(string $name, mixed …$args): mixed
{
if (!isset($this->registry[$name])) {
throw new \InvalidArgumentException(“Service not found”);
}
// 可変関数呼び出し（Dynamic Call）はZend VMにとっても最適化が難しいため、
// 計算集約型ロジックとは別レイヤーに隔離する
return ($this->registry[$name])(…$args);
}
}
このように、アプリケーションの構造を「計算・データ処理層（JIT最適化が活きる場所）」と「構造化・ディスパッチ層（動的でZend VMの柔軟性に頼る場所）」に綺麗にレイヤリングすること。これが、PHP 8のJIT性能をエンジニアの意図通りに引き出すための最大の極意です。
—
4. アーキテクトからのまとめ
今回は、PHP 8.xのJITコンパイラが内部のZend VMやメモリ空間でどのように動き、私たちがコード設計や構造分離によってどうアプローチすべきかを解説しました。
- トレーシングJITはホットループを監視し、効率的な中間表現（IR）を経てネイティブコードへ変換する。
- 型が明確なコード（Monolithic/Strict）はJITの爆発的な高速化の恩恵を受ける。
- 逆に動的すぎるコードや複雑なディスパッチは、責務を分離してアーキテクチャレベルで棲み分けるのがプロの技。
「なんとなく速くなりそうだからJITを有効にする」のではなく、PHPのエンジンが内部でどうメモリを扱い、どうオペコードを処理しているかという解像度を持つことで、あなたの書くコードは一歩上の洗練されたシステムへと昇華されます。
ぜひ、日々の設計やパフォーマンスチューニングの引き出しに、このZend VMの視点を加えてみてくださいね。