JITコンパイルされたコードと非コンパイルコードの境界：Deoptimization（脱最適化）発生時のコストとスタックフレームの再構築
PHP 8におけるJIT（Just-In-Time）コンパイラの導入は、スクリプト言語としてのPHPのパラダイムシフトであった。DynASMをベースに実装されたLuaJITスタイルのJITエンジンは、Zend VMのオペコード（Opcode）をネイティブの機械語（x86/x64）へと直接コンパイルし、CPUのパイプラインを極限まで効率化する。
しかし、動的型付け言語であるPHPにおいて、JITが常に最高速度を維持できるわけではない。JITコードが前提としていた「型」の仮定が崩壊した瞬間、エンジンはネイティブ実行の世界から、重厚なZend VMの世界へと強制的に引き戻される。これがDeoptimization（脱最適化）である。
本稿では、このDeoptimizationが発生する内部メカニズム、ネイティブスタックフレームからZend VMスタックフレームへの再構築コスト、そしてそれを回避するための型設計の極意を、Zend Engineの深部から紐解いていく。
—
1. Zend VMとJITの境界：ガード（Guard）の正体
JITコンパイラが生成するネイティブコードは、常に楽観的（Optimistic）な前提に基づいている。例えば、次のような単純な加算関数を考えてみる。
function calculate_sum(int $a, int $b): int {
return $a + $b;
}
厳格な型宣言（`int`）が存在する場合でも、Zend VMの動的性質上、JITは「この変数は常に`IS_LONG`（整数型）である」という仮定（Guard）を挿入した上で、ネイティブの加算命令（`ADD`）へとコンパイルする。
しかし、JITはこのガード条件が破られた瞬間のための「逃げ道」を用意しなければならない。これがSide Exit（サイドエキシット）と呼ばれる機構である。
Guardの破綻とSide Exit
もし、実行時に何らかの理由で変数が`IS_DOUBLE`や`IS_STRING`に変異した場合（あるいは型チェックが無効なコンテキストで動的呼び出しが行われた場合）、ネイティブコード上のGuardは即座に失敗（Fail）する。
この瞬間、CPUの実行ポインタはJIT領域から、あらかじめ用意されたエグジットスタブへとジャンプする。これがDeoptimizationのトリガーである。
—
2. Deoptimization発生時のコストとスタックフレームの再構築
Deoptimizationが恐ろしいのは、単に「遅いコードにフォールバックする」だけではない点にある。ネイティブのレジスタ上で高速に処理されていた変数の状態を、Zend VMが解釈できる「スタックフレーム（`zend_execute_data`）」へと完全に同期・再構築（Reconstruct）しなければならない。
内部構造の同期プロセス
1. レジスタ退避とコンテキスト復元:
ネイティブのCPUレジスタ（RAX, RBXなど）に保持されていたローカル変数の値を、メモリ上の`_zval_struct`へと書き戻す。
2. スタックフレームの巻き戻しと再構築:
ネイティブ関数呼び出しのコールスタックを解析し、Zend VMのインストラクションポインタ（`opline`）と実行データ（`zend_execute_data`）を逆算して構築する。
3. VMインタープリタへの制御移譲:
構築された`zend_execute_data`をZend VMのメインループ（`zend_execute()`）に渡し、インタープリタ実行へと復帰する。
この一連のプロセス（特にレジスタからzvalへの逆変換とメモリレイアウトの再構築）は、CPUキャッシュのヒット率を著しく低下させ、数千サイクル規模のストールを引き起こす。JITの恩恵を受けていたはずの処理が、頻繁なDeoptimizationによって、素のZend VMで実行するよりも遥かに遅くなる現象は、このフレーム再構築のオーバーヘッドに起因する。
—
3. 型の不一致を引き起こすアンチパターンと実例
実務において、JITのパフォーマンスを完全に殺すコードの典型例を見てみよう。以下のコードは、一見すると何の問題もないように見えるが、内部で激しいDeoptimizationを引き起こす爆弾を抱えている。
/
class MetricsProcessor {
private $value;
public function __construct($value) {
// コンストラクタで型を固定しない（スカラー型の混入）
$value = $value;
}
public function process(): int {
// ここで厳密なintを期待しているが、$this->valueがfloatやstringに化ける可能性がある
return $this->value 2;
}
}
// JITが有効な環境下でのホットループ
$processor = new MetricsProcessor(100);
for ($i = 0; $i < 1_000_000; $i++) {
// 途中から浮動小数点や文字列が混入すると想定
if ($i === 500_000) {
// 内部プロパティの型がIS_LONGからIS_DOUBLEに変化
// これにより、process()内の乗算オペコードのJITガードが崩壊する
ReflectionClass::export(MetricsProcessor::class); // （例示用のメタファー）
}
$result = $processor->process();
}
JITの最適化を殺さないための極意
JITコンパイラの恩恵を極限まで引き出し、Deoptimizationの悪夢を回避するためには、以下のアーキテクチャ上の制約をコードに課す必要がある。
1. プロパティと変数のモノモーフィック（単一型）化:
Zend VMのJITは、ポリモーフィック（多態的）な変数やプロパティの型推論を苦手にしている。クラスプロパティやメソッドの引数・戻り値には、必ず厳格なスカラー型宣言（`int`, `float`, `string`等）を付与し、動的な型変更（Type Juggling）をコードベースから排除する。
2. ストレージ層での型の正規化:
データベースや外部APIから取得したデータ（多くは文字列や混在配列）は、ビジネスロジック層に侵入する前に、必ず明示的なキャスト（`$id = (int)$row[‘id’];`）を行い、Zend Engineが認識する`zval`の型タグを早期に確定させる。
3. OPcacheとJITのバッファチューニング:
`php.ini`において、JITのコードバッファサイズ（`opcache.jit_buffer_size`）が不足していると、頻繁なコードの破棄と再コンパイルが発生し、Deoptimizationと相まってパフォーマンスが急落する。大規模システムでは最低でも`128M`以上のバッファを割り当て、トレースバッファの最適化を行うべきである。
[opcache]
opcache.enable=1
opcache.enable_cli=1
opcache.jit_buffer_size=256M
opcache.jit=1255
(※ `jit=1255` は、関数単位のトレーシングJITを有効にし、コストパフォーマンスと最適化のバランスを極限まで高める設定値である)
—
4. チーフアーキテクトからの提言：コードは「型」で語れ
PHPは動的言語としての柔軟性をアイデンティティとして持ってきた。しかし、現代のハイパフォーマンスWebシステムにおいて、その「甘え」はCPUサイクルとメモリ帯域の無駄遣いである。
JITコンパイラとZend VMの境界を支配する者は、PHPの実行速度を支配する。変数にどのような型が入るのかをプログラマが完全に把握し、エンジンに「迷い」を与えないコードを書くこと。それこそが、PHPコアの限界を突破し、秒間数万リクエストを捌く超高負荷システムを構築するための唯一にして最大の王道である。