こんにちは。日々のWebアプリケーション開発、本当にお疲れ様です。
JavaやC#、あるいはNode.jsといった他の高水準言語のバックグラウンドを持つ優秀なエンジニアほど、PHPのコードを書いているときにふと「この手元の一行が、裏側のZendエンジンでどう解釈されているんだろう？」と立ち止まる瞬間があるのではないでしょうか。
「PHPはインタプリタ言語だから遅い」——そんな神話は、PHP 7でのZend VMの刷新、そしてPHP 8におけるJIT（Just-In-Time）コンパイルの導入によって、完全に過去のものとなりました。
しかし、このJITコンパイルが「いつ、どのコードをネイティブの機械語に変換しているのか」を正確に理解している人は、シニアエンジニアの間でも意外と多くありません。「JITを有効にしたけれど、思ったほどパフォーマンスが上がらない」「むしろオーバヘッドになっている気がする」そんな壁にぶつかったことはありませんか？
今回は、PHP 8.xの心臓部であるJITコンパイラ、特に「Function JIT」と「Tracing JIT」の選択アルゴリズムとホットパス検出の内部ロジックに深く潜ってみましょう。ここを理解すると、PHPの裏側の世界が驚くほど美しく見えてきますよ。
—
1. Zend VMの基本と「JIT」が生まれる場所
まず、私たちが普段何気なく書いているPHPコードが、1リクエストの中でどう処理されているかを脳内トレースしてみましょう。
オペコード（Opcode）へとコンパイルされます。従来、PHPはこのオペコードをZend VMの巨大な`switch`文（またはGCCの拡張機能であるComputed Goto）で1つずつ解釈・実行していました。CPUから見ると、これはメモリアクセスの局所性が悪く、分岐予測ミスが頻発する非効率なループです。
そこでOPcacheのJITが登場します。JITは、実行時（Run-time）に頻繁に実行されるオペコードの塊を、CPUが直接理解できるネイティブマシン語（x86_64やARM64の機械語）へとコンパイルし、CPUのキャッシュに載せて直接実行してしまう技術です。
PHP 8のJITには、主にFunction JITとTracing JITという2つの戦略が用意されています。この2つがどう使い分けられているのか、その内部ロジックを紐解いていきましょう。
—
2. Function JIT：関数単位の静的な昇格
最初からエンジンに組み込まれていたアプローチが Function JIT です。
内部挙動の仕組み
Function JITのアルゴリズムは非常にシンプルです。
1. スクリプトの読み込み（コンパイルフェーズ）時、あるいは関数が最初に呼び出されたタイミングで、その関数全体のオペコードを監視します。
2. その関数が「ホット（頻繁に呼び出されている）」と判定されると、関数全体を丸ごとネイティブマシン語にコンパイルします。
設定としては、`php.ini` の `opcache.jit_buffer_size` を確保した上で、JITの挙動を制御する `opcache.jit` 制御値（例: `1255` や `1235` など）の百の位や一の位でその性格を決定します。
Function JITの限界
直感的で分かりやすい反面、Function JITには「関数のなかに、一度しか通らないエラー処理や巨大な条件分岐が含まれていても、そのすべてを機械語にしてしまう」という無駄があります。メモリ（JITバッファ）を圧迫しやすく、Webアプリケーション特有の「短命なリクエストの中で、無数の小さな処理が走る」というワークロードにおいては、必ずしも最適解とは言えません。
そこでPHP 8がデフォルトで採用したのが、より高度な Tracing JIT です。
—
3. Tracing JIT：ホットパス（Hot Path）検出の内部ロジック
現代のJITコンパイラ（JavaのHotSpot VMや、かつてのHHVMなど）の主流である「トレーシング」が、PHP 8にも導入されました。これが本記事の核心です。
ホットパスとは何か？
Webアプリケーション全体を見渡したとき、CPU時間の80%以上はコード全体のわずか数％（例えば、フレームワークのルーティング判定ループや、ORMのオブジェクト水和（Hydration）処理）で消費されています。この「何度も実行される熱いループや処理の流れ」のことをホットパス（Hot Path）と呼びます。
Tracing JITは、関数全体ではなく、この「実際に実行されているループや分岐の軌跡（Trace）」単位で最適化を行います。
内部プロファイリングとカウンタの仕組み
Zend VMの内部では、すべてのループ（`ZEND_JMP` や `ZEND_DO_FCALL` などのジャンプ系オペコード）に実行カウンターが仕込まれています。
1. カウンタのインクリメント:
コードがループを回るたびに、Zend VMの内部カウンターが増加します。
2. トリガーの閾値:
このカウンターが一定の閾値（OPcacheの内部ロジックおよび設定で管理されるプロファイル値）を超えると、エンジンは「お、このループは何度も回っているな。ホットパスかもしれない」と検知します。
3. 記録（Recording）フェーズ:
検知されると、Zend VMは一時的に「レコーディングモード」に入ります。そのループが実際にどのような順序でオペコードを通過し、どのような型（整数なのか、オブジェクトなのか）の変数を扱っているかをリアルタイムでトレース（記録）します。
4. JITコンパイルとJITルールの適用:
記録されたトレース情報に基づき、無駄な分岐や型チェックを省いた最適化されたネイティブマシン語が生成され、JITバッファに書き込まれます。次回からは、VMをバイパスして直接そのネイティブコードが実行されます。
—
4. 実務で活かす：JITの挙動をコントロールする `php.ini` の極意
「理屈は分かったけれど、実際のプロダクション環境ではどう設定すべきなの？」という疑問が湧きますよね。
`php.ini` における `opcache.jit` の設定値は4桁の整数（例: `1255`）で指定します。それぞれの桁がJITの挙動を細かく制御しています。
[opcache]
opcache.enable = 1
opcache.jit_buffer_size = 100M
; デフォルトの推奨設定（Tracing JITを有効化）
opcache.jit = 1255
この `1255` という値を、左から順にアーキテクトの視点で分解してみましょう。
1. CPU特化フラグ（千の位: `1`）:
CPUの拡張命令（AVXなど）を使用するかどうか。通常は `1` または `0`。
2. 最適化レベル（百の位: `2`）:
最適化の度合い。数字が大きいほどアグレッシブな最適化（レジスタ割り当てやインライン展開など）を行います。
3. 実行トリガー（十の位: `5`）:
いつJITコンパイルを開始するか。関数単位で行うか、Tracing JITを使うかを指定します。`5` を指定するとTracing JITが有効になり、ループの実行回数に応じてホットパスを検出します。
4. JITの種別・動作（一の位: `5`）:
関数単位のJITにするか、トレース単位にするかの詳細なポリシーを決定します。
アーキテクトからの実践的なアドバイス
CRUD中心の一般的なWebアプリケーション（WordPressやLaravelを使った通常のWebサイトなど）においては、データベースI/OやネットワークI/Oがボトルネックになるため、JITの効果が体感しにくい場合があります。
しかし、次のようなCPUバウンドな処理がアプリケーションに含まれている場合、Tracing JITはその真価を発揮します。
- 大量のデータ処理、JSONのシリアライズ/デシリアライズ
- 暗号化・ハッシュ化処理
- 独自ドメインロジックでの複雑な計算や、深いループ構造を持つアルゴリズム
このような処理を実行するコードブロックでは、Tracing JITが型情報を正しく推論できるように、変数の型を途中でコロコロ変えない（動的な型変更を避ける）コーディングを心がけると、JITの最適化パス（Guardの維持）が非常に効率よく働き、劇的なパフォーマンス向上をもたらします。
—
まとめ
今回は、PHP 8.xのJITコンパイラが裏側でどのようにコードをプロファイルし、Function JITとTracing JITを使い分けているのか、その物理的・内部的な挙動を解説しました。
- Zend VMは、実行中のループのカウンターを監視し、頻繁に踏まれるホットパスを見つけ出す。
- Tracing JITは、関数単位ではなく、その実行の「軌跡」を記録してネイティブマシン語へと昇格させる。
- エンジンの内部挙動を意識したコードを書くことで、JITの恩恵を最大限に引き出すことができる。
「PHPはただ動くだけのスクリプト言語ではない。下層では洗練されたZendエンジンが、ダイナミックにマシン語を生成して駆動している」——この事実を知れただけでも、あなたのPHPコードに対するアプローチは一段も二段も深くなったはずです。
ぜひ、日々の開発やパフォーマンスチューニングの現場で、この知見を思い出してみてください。裏側のエンジンと対話するような、新しいプログラミングの面白さがそこには待っていますよ。