こんにちは。日々のWebアプリケーション開発、本当にお疲れ様です。
JavaやGo、あるいはNode.jsといった他の高水準言語の世界からPHPへとやってくると、その圧倒的な開発スピードの裏側にある「1リクエストごとにすべてを破棄して無に帰す」という潔いライフサイクルに驚かされることでしょう。
しかし、その「割り切り」こそがPHPを最もシンプルで堅牢なWebの特化言語たらしめている理由です。そしてPHP 8の登場により、その動的解釈の限界を打ち破る「JIT（Just-In-Time）コンパイラ」が私たちの手に入りました。
今回は、このJITコンパイラの心臓部である「Function JIT」と「Tracing JIT」の2つのモードについて、Zend VMの内部挙動とメモリ配置の観点から深く掘り下げていきましょう。「なんだか設定してみたけれど、劇的に速くなった実感がない」「どっちを有効にすべきか迷っている」という壁にぶつかっているなら、ここから先の世界を知ることで、PHPの裏側が驚くほど美しく見えてくるはずです。
—
1. Zend VMの基本と、JITが介入する瞬間
まず、PHPのコードが実行されるまでの背後を軽くおさらいしておきましょう。
私たちが書いたPHPスクリプトは、レキシカル解析と構文解析を経て、Zend Opcodes（オペコード）という中間表現にコンパイルされます。伝統的なPHPでは、このオペコードの配列をZend VMがC言語の巨大な `switch` 文ベースの仮想マシン（エスイー・ループ）で1つずつ解釈実行していました。この「解釈（Interpretation）」のオーバーヘッドを削ぎ落とすのがJITの仕事です。
JITが有効になると、Zend VMは特定の条件を満たしたオペコードの塊を、CPUが直接理解できるネイティブマシン語（x86_64などの機械語）へとコンパイルし、プロセス上の専用メモリ空間（Hugepages等で確保された実行可能メモリ領域）に書き込みます。
ここで重要なのは、「どの単位でマシン語に変換するか」というアプローチの違いです。それが、これから解説するFunction JITとTracing JITの分かれ道になります。
—
2. Function JIT：関数単位の愚直なアプローチ
概念と内部挙動
Function JITはその名の通り、「PHPの関数単位」でネイティブコードへのコンパイルを行います。
Zend VMがスクリプトを実行していく中で、ある関数が頻繁に呼び出されると、エンジンはその関数全体のオペコードを丸ごとネイティブマシン語に翻訳します。生成されたコードは関数の構造体（`zend_function`）に紐付けられ、次回以降はその関数のエントリーポイントを叩くだけで、Zend VMのインタプリタをバイパスしてCPUが直接処理を実行します。
メリットと弱点
- メリット: 実装が比較的シンプルであり、関数全体の構造がそのままマシン語になるため、コンパイルの予測がつきやすい。
- 弱点: 関数の中に「めったに通らない巨大なエラーハンドリングの分岐」や「型が揺らぐループ」が含まれていると、その部分も含めてすべてマシン語にコンパイルされるため、メモリ（I-cache：命令キャッシュ）効率が悪化します。また、現代のWebアプリケーションのように数千の小さな関数が入り組んでいる構造では、恩恵を受けにくい傾向があります。
—
3. Tracing JIT：実行パスを追跡する高度なアプローチ（PHP 8のデフォルト）
概念と内部挙動
PHP 8でデフォルト採用されたのが、このTracing JITです。こちらは「関数」単位ではなく、「実際に頻繁に実行されるコードの経路（トレース）」を単位としてコンパイルを行います。
Zend VMは、ループ構造やホットスポット（高頻度で実行されるブロック）を監視し、「おっ、このループは何回も回っているな」と検知すると、その実行時のパス（Trace）だけを切り取って記録します。そして、その実際に通った道筋だけを最適化してマシン語に変換するのです。
言葉を変えれば、「実際に動いた証拠があるコードの断片だけを極限まで高速化する」という、非常にスマートなアプローチです。
メリットと弱点
- メリット: 使われない分岐（Dead Codeやレアケースの例外処理）をコンパイル対象から除外できるため、CPUのI-cacheのヒット率が劇的に向上します。動的な型付け言語であるPHPにおいて、型が確定しているホットなループを爆速にするのに最適です。
- 弱点: 実行時のプロファイリングとトレースの構築に若干のオーバーヘッドがかかります。短命なスクリプト（数ミリ秒で終わるCLIタスクなど）では、コンパイルコストがリターンを上回ってしまうことがあります。
—
4. どっちを使うべき？設定値（`opcache.jit_buffer_size` と `opcache.jit`）の正解
`php.ini` における `opcache.jit` 設定は、4桁の整数（例: `1255` や `1235`）で挙動を制御します。ここがアーキテクトの腕の見せ所です。
Tracing JIT（デフォルト・推奨）を採用すべきケース
一般的なWebアプリケーション（Symfony、Laravel、WordPressなど）で、CPUバウンドな処理（複雑な計算、データ構造のシリアライズ、画像処理、巨大な配列操作など）を高速化したい場合は、Tracing JIT（設定の百の位が `2`）を強く推奨します。
; php.ini の推奨設定例 (Tracing JIT)
opcache.enable = 1
opcache.jit_buffer_size = 100M
opcache.jit = 1255
> ここがポイント：
> `opcache.jit = 1255` の千の位・百の位の意味を紐解くと、内部的なCPU特有の最適化フラグや、トレース生成のトリガーが綺麗に調整されます。百の位が `2` であることが「Tracing JIT」を指定する鍵です。
Function JITを採用すべきケース
もし、あなたのアプリケーションが「非常に多くの異なる小さな関数を均等に呼び出す」構造であり、ホットなループを持たない場合、あるいはメモリ使用量を極限まで切り詰めたい組込み・特殊環境であれば、Function JIT（百の位が `1`）を試す価値はあります。しかし、現代のモダンなWebアーキテクチャにおいては、Tracing JITのパフォーマンス特性が圧倒的に優位に働きます。
—
5. ベンチマークとプロファイリングによる判断基準
「なんとなく速そうだからJITをONにする」のではなく、エンジニアとしてデータで語れるようになりましょう。
JITが実際に効いているかどうかを確かめるには、単なるレスポンスタイムの計測だけでなく、Opcodesの挙動とCPUのキャッシュ効率を見る必要があります。
1. JITの稼働確認
`php -i` または `phpinfo()` を実行し、Opcodesのセクションを確認します。
JIT => On
JIT Buffer => 104857600 bytes
これでバッファが正しく確保されていることがわかります。
2. プロファイリングによる見極め
もしアプリケーションのボトルネックが「データベースのI/O待ち」や「外部APIのレイテンシ」である場合、どれほど優秀なJITを走らせても体感速度は1ミリ秒も変わりません。JITが真価を発揮するのは、純粋なCPUバウンド（CPUの演算能力がボトルネックになる状態）の処理です。
- 判断基準 A（JIT不適合）: プロファイラ（BlackfireやXdebugなど）で計測した際、実行時間の8割以上がI/O待ち（PDO、CURL、ファイル読み書き）に費やされている。
- ⇒ 対策: JITのチューニングよりも、クエリの最適化やキャッシュ層（Redis等）の導入を優先すべきです。
- 判断基準 B（JIT適合）: 配列の大量操作、カスタムアルゴリズムの実行、ドメインロジックのループ処理などでCPU使用率が100%に張り付いている。
- ⇒ 対策: `opcache.jit_buffer_size` を十分に確保し、Tracing JITを有効化することで、処理時間を最大数倍に引き上げることができます。
—
まとめ：PHPの裏側を掌握する
いかがでしたでしょうか？
Function JITが「関数単位の愚直なコンパイル」であるのに対し、Tracing JITが「実行パスを追いかける洗練された最適化」であること、そしてそれがZend VMのメモリ空間やCPUキャッシュとどう結びついているのかが見えてきたかと思います。
PHPはもはや「ただの簡単なスクリプト言語」ではありません。内部のメモリ管理やJITの特性を理解して適切に調律してやれば、下位レイヤーのコンパイル言語に匹敵するほどの鋭い牙を向く、極めてモダンで強力なプラットフォームへと変貌します。
ぜひ、ご自身のアプリケーションのプロファイルを取りながら、最適なJITモードとバッファサイズを探求してみてください。PHPの裏側が綺麗に見えたとき、あなたのコードを書くアプローチもきっと、一段上の洗練されたものに変わっているはずです。