こんにちは。普段は他のモダンなプログラミング言語（TypeScriptやGo、Rustなど）をバリバリ書きつつ、「なんだかんだでWebのトラフィックを支えるのはPHPのスピードだな」と向き合っているうちに、気がつけばZend VMのソースコードまで覗き込んでしまった……そんな優秀な開発者の方って、最近とても多いですよね。
フレームワークのルーティングやORMの抽象化層を綺麗に設計し、「さあ本番だ」と負荷をかけたとき、ふと疑問に思いませんか？
「PHP 8のJITって、実際にどのコードをどうやって選んでネイティブコードにコンパイルしているんだろう？」と。
ネット上を検索すると、「PHP 8でJITが入って速くなりました！」という表面的なベンチマーク記事ばかりが出てきますが、私たちアーキテクトが知りたいのはそこじゃありません。Zend VMが実行時にメモリ上でどう動き、どの瞬間にプロファイリングのカウンターが閾値を超え、ネイティブの機械語へと化けるのか。その「低レイヤのドラマ」を知りたくありませんか？
今回は、PHP 8.xの心臓部であるJITコンパイラのトレース選択アルゴリズムについて、Zend VMの内部構造とメモリ空間の挙動を交えながら、優しく、そして深く紐解いていきたいと思います。ここを理解すると、あなたの書くPHPコードのパフォーマンスの見え方がガラリと変わりますよ。
—
1. Zend VMの基本と「JITはいつ目覚めるのか」
PHPは基本的にインタプリタ言語です。私たちが書いたコードは、パーサによって抽象構文木（AST）に変換され、最終的にZend VMが解釈実行するためのオペコード（Opcode）の配列へとコンパイルされます。
通常のリクエストライフサイクルにおいて、Zend VMはオペコードの配列を上から順にポインタを進めながら、巨大な`switch`文（あるいはGCCの拡張機能であるComputed Goto）で一つずつハンドラを実行していきます。この「インタプリタとしてのオーバーヘッド」を打ち破るのがJITです。
しかし、PHPのJIT（DynASMをベースに実装されています）は、最初からすべての関数をネイティブマシン語にコンパイルするわけではありません。そんなことをすれば、起動時のメモリ消費とコンパイルコストだけでサーバーが窒息してしまいます。
そこで重要になるのが、「ホットコード（Hot Code）の動的特定」です。
プロファイリングカウンターの正体
Zend VMは、スクリプトの実行中、常に各オペコードや関数、ループが「何回実行されたか」を監視しています。これが実行時プロファイリングデータです。
内部的には、関数構造体（`zend_function`）やオペコードのエントリポイントにカウンタが仕込まれており、ループバック（ジャンプ命令）や関数の呼び出しが行われるたびに、このカウンタがインクリメントされます。
/ 概念的なZend VMのカウンタ更新イメージ（C言語ベースの拡張視点） /
ZEND_VM_HOT_C_COUNTER++;
if (ZEND_VM_HOT_C_COUNTER > JIT_TRIGGER_THRESHOLD) {
// ここでJITコンパイルのトリガーが引かれる
zend_jit_trig_compile(op_array);
}
この閾値（`opcache.jit_buffer_size`や各種トリガー条件）を超える頻度で実行されるパスこそが、JITにとっての「ごちそう（＝トレース対象）」になるのです。
—
2. 関数JIT（Function JIT） vs トレースJIT（Trace JIT）
PHP 8のJITには、主に2つのモードが存在します（`opcache.jit_debug`や設定値の`tracing`等で制御されます）。
1. Function JIT: 関数全体を丸ごとネイティブコードに翻訳する。
2. Trace JIT: 関数全体ではなく、「実際に何回も高頻度で実行されている特定のループや条件分岐のパス（トレース）」だけを切り取って翻訳する。
実は、PHP 8でデフォルト採用されているのは後者のトレースJITです。なぜ関数丸ごとではなく「トレース」なのか？ ここにPHPの動的型付き言語としての苦悩と、それを鮮やかに解決する知見があります。
PHPの変数は型が実行時に変わりますよね（ポリモーフィズム）。関数全体をコンパイルしようとすると、「この変数が整数なのかオブジェクトなのか分からない」という分岐（ガード）を大量に生成しなければならず、ネイティブコードが肥大化してしまいます。
しかし、「実際に通った道（トレース）」だけを切り出せば、その瞬間における変数の型は固定化されていることが多いのです。
—
3. トレース選択アルゴリズムのトリガー条件と内部挙動
では、JITは具体的にどのようにしてトレースを選ぶのでしょうか。そのアルゴリズムのステップを、メモリと実行コンテキストの動きに合わせて追ってみましょう。
ステップ①：ホットスポットの検知（カウンタの爆発）
アプリケーションが動き出し、例えば次のような重いループ処理があるとします。
「ホット」と認定されます。
ステップ②：トレース記録の開始（Recording Mode）
ホットと判定されたエントリポイントから、Zend VMは一時的に「レコーディングモード（記録モード）」に入ります。
このモード中、VMは通常通りの処理を行いつつ、「実際にどのオペコードがどのような順序で実行され、その時の変数の型はどうだったか」という実行トレースログをJITの内部バッファに記録していきます。
ステップ③：ガード（Guard）の挿入と最適化
レコーディングされたトレースをネイティブコード（マシン語）に変換する際、JITコンパイラは非常に巧妙な仕掛けをします。それが「ガード（型・状態の監視）」です。
「この変数は今のところ float 型だけど、次のリクエストでは string 型が来るかもしれない」
JITはトレースの先頭や分岐点に、高速な型チェックの機械語（ガード）を差し込みます。
もし実行時にその型が一致していれば、超高速なネイティブコード領域をそのまま駆け抜けます。もし型が変わり、ガードが破綻（ミス）した場合は、何が起きるでしょうか？
「JITの脱出（Side Exit）」が発生します。
ガードが外れた瞬間、処理は即座に通常のZend VMのインタプリタ実行に戻されます。プログラムがクラッシュすることは絶対にありません。この「安全ネットを張った上で極限まで加速する」という設計こそが、PHPのJITの美しさです。
—
4. アーキテクト視点：JITを味方につけるためのコード設計
ここまでZend VMの内部挙動を見てくると、「どういうPHPコードがJITに愛され、どういうコードが無視されるのか」がクリアに見えてきますよね。
最後に、実務の現場でJITの恩恵を最大限に引き出すための実践的な知見をいくつかシェアしておきます。
1. 型の揺れ（ポリモーフィズム）を極力減らす
JITがトレース中に生成する「ガード」は、型が頻繁に変わるコード（例：引数にintもobjectもごちゃ混ぜで渡すようなメソッド）ではすぐに破綻します。サイドexitが頻発し、逆にインタプリタよりもオーバーヘッドが増える「JITアンチパターン」に陥ります。
スカラー型宣言（`int`, `float`, `string`）や厳密な引数・返り値のタイピングを行うことは、コードの保守性だけでなく、JITの最適化効率を劇的に上げるためにも極めて重要です。
2. 配列（HashTable）の密な操作
PHPの配列（`array`）は内部的には強力なハッシュテーブル（`HashTable`）ですが、数値添字で連続した配列（いわゆるベクターに近い状態）は、JITによって効率的に最適化されやすいメモリレイアウトの恩恵を受けます。不必要に複雑な多次元の連想配列をこねくり回すよりも、シンプルな構造を維持する方が、JITのトレース生成において有利に働きます。
—
おわりに：裏側を知れば、PHPはもっと面白くなる
今回は、PHP 8のJITコンパイラが裏側でどのようにプロファイリングデータを集め、トレースを選択し、ネイティブコードへと昇華させているのかを、Zend VMのメモリ空間や実行コンテキストの視点から解説しました。
「PHPは遅いインタプリタ言語だ」なんて言葉は、もう過去のものです。Zend VMの仕様とJITの挙動を正しく理解し、それに合わせた美しいコードを書けば、PHPはモダンなコンパイル言語に匹敵する爆発的なパフォーマンスを発揮します。
ぜひ、日々の開発の中で「このループ、今JITはどうトレースしているだろう？」と、脳内でZend VMのオペコードをトレースしてみてください。きっと、コードを書くのがこれまで以上に楽しくなりますよ。