PHP 8.x Union Typesの底流：Zend VMの型判定コストとJITが描くネイティブコードの境界
PHP 8.0で導入されたUnion Types（共用体型）は、PHPを「動的言語の皮をかぶった堅牢な静的型付け言語」へと変貌させたマイルストーンである。`int|string` や `User|null` のような表現は、ドキュメントの価値を劇的に高め、静的解析ツールによるバグ検知の精度を極限まで引き上げた。
しかし、Webシステムアーキテクトの視点に立つとき、我々が常に問い直さなければならないのは「その美しさの裏で、Zend VM（Zend Virtual Machine）のメモリ空間とCPUサイクルの消費はどう変化しているのか」という残酷な物理的現実である。
本稿では、PHP 8.xにおけるUnion Typesが実行時にどのようなオペコード（Opcode）を生成し、Zend Engineが如何なるコストを支払いながら型判定を行っているのか、そしてJIT（Just-In-Time）コンパイラがそのオーバーヘッドをどのように消去するのかを、低レイヤのメモリ構造とともに対峙する。
—
1. Zend VMのデータ構造：`zval` と型情報の物理配置
PHPのすべての変数は、C言語レベルにおいて `zval`（Zend Value）という構造体によって表現される。PHP 8における `zval` は16バイト（64ビット環境）に最適化され、その内訳は以下のようになっている。
- Value（8バイト）: 実際のスカラ値、あるいはヒープ上の構造体（`zend_string`, `zend_object`, `zend_array` 等）へのポインタ。
- Type Info（4バイト）: 型情報（`IS_LONG`, `IS_STRING`, `IS_OBJECT` など）および修飾子。
- Additional Info（4バイト）: ガベージコレクション用の情報やハッシュの計算結果など。
従来のPHP（PHP 7.x以前）の単一型ヒント（例：`int $param`）であれば、Zend VMはオペコードの実行前段階（あるいは引数受渡しの瞬間）に、`zval` の `u1.v.type` が `IS_LONG` であるかを一回比較するだけで済んでいた。これはC言語レベルで単なる `Z_TYPE_P(val) == IS_LONG` という数クロックの比較命令（分岐予測が極めて容易な `cmp` と `je`）に帰結する。
しかし、これが `int|string` になった瞬間、判定ロジックは分岐の連続へと変貌する。
—
2. オペコードレベルでの型判定コスト：`ZEND_RECV_INIT` と型アサーション
Union Typesを指定した関数やメソッドに引数を渡す際、Zend VMは単一の型チェックではなく、許可された型フラグのビットマスク（Bitmask）との照合、あるいは複数の型に対する条件分岐を実行時に行う。
以下のPHPコードを考えてみす。
3. JITコンパイラによる最適化：Native Machine Codeへの翻訳
この実行時コストを劇的に粉砕するのが、PHP 8で導入された DynASMベースのJITコンパイラ である。OPcacheのJITが有効な場合、Zend VMのバイトコードは実行時（あるいはプリロード時）に直接CPUのネイティブ機械語（x86-64等）へとコンパイルされる。
JITは、Union Typesの型判定コストをどのように扱うのか。
プロファイリングに基づく型特化（Type Specialization）
JIT（Tracing JIT）は、コードが実行されるにつれて、そのパスを通過する実際のデータの型を監視（プロファイル）する。
もし `process_payload(int|string $payload)` が、実行時間の99%において `int` しか受け取っていないことをJITが検知した場合、JITは次のようなネイティブマシンコードを生成する。
; 概念的なx86-64ネイティブコード（JIT出力）
; 引数ポインタがRDIレジスタにあるとする
mov rax, [rdi + 8] ; zvalのtypeフィールドを取得
cmp rax, 4 ; IS_LONG (4) と比較
jne .slow_path ; もしintでなければスロー・フォールバックパスへ
; — 高速パス（Fast Path）: 純粋なintとしての処理 —
mov rsi, [rdi] ; 数値の実体を取得
; … 以降、ネイティブな加算演算等へ直結 …
ret
.slow_path:
; string型やその他の判定、あるいはZend VMへの制御委譲
call zend_type_error_or_string_handler
JITが効いた状態では、Union Typesであっても「頻出する型（Dominant Type）」の分岐が予測可能になり、インラインキャッシュやJITの最適化パスによって、実質的に単一型と同等の速度までコストが削ぎ落とされる。
しかし、引数の型が完全にランダム（例えば、1回目は `int`、2回目は `string`、3回目は `float`）であるような悪夢のようなコードでは、JITはメガモーフィック（Megamorphic）な状態に陥り、効率的なネイティブコードへの変換を諦め、Zend VMの汎用ハンドラへとフォールバックする。結果として、JITの恩恵は消失し、純粋なオーバーヘッドのみが残る。
—
4. OPcacheプリローディングとメモリ空間の物理構造
このパフォーマンスの攻防を支えているのが、PHP 8の OPcache Preloading である。
プロセスのライフサイクルにおいて、FPM（FastCGI Process Manager）のワーカープロセスが起動する際、`opcache.preload` で指定されたスクリプト群は、親プロセス（Master）のメモリ空間上でコンパイルされ、共有メモリ（SHM: Shared Memory）へと書き込まれる。
[ OPcache Shared Memory (SHM) ]
├── zend_class_entry (User)
├── zend_function (process_payload)
│ └── op_array (オペコード配列)
│ ├── ZEND_RECV_INIT
│ ├── ASSERTS_TYPE_AND_CONVERT (Union Typesメタデータ含む)
│ └── …
└── 共有メモリ空間（全FPMチルドプロセスから読み取り専用でマップ）
Union Typesの定義（例：`int|string`）は、コンパイル時に `zend_type` 構造体として表現され、この共有メモリ内に静的に配置される。
チルドプロセス（Worker）は、フォーク（`fork()`）された瞬間から、この共有メモリ上の `zend_class_entry` や `op_array` をCopy-On-Write（COW）の原則に基づき、高速に参照する。
ここでセキュリティとメモリ効率の観点から重要なのは、「Union Typesの型メタデータ自体は、起動時に一度だけパースされ、不変の共有メモリ上にロックされる」という点である。実行時に動的な型定義のパースは行われないため、メモリの断片化（Fragmentation）やアロケータ（emalloc/zend_mm_heap）への負荷は最小限に抑えられている。
—
5. 極限の知見：静的解析と動的実行の狭間で
アーキテクトとしてシステムを設計する際、PHP 8のUnion Typesを採用するかどうかは、単なる「コードの表現力」の議論ではない。
1. 深いUnion Types（例：`A|B|C|D|null`）の罠:
型の数が増えれば増えるほど、Zend VMの型アサーションにおける分岐命令の数が増加し、JITがトレースを生成する際のパスが爆発的に複雑化する。ホットパスにおける多重のUnion Typesは、CPUのキャッシュミスと分岐予測ミスの温床となる。
2. Strict Typesの強制:
`declare(strict_types=1);` を記述しない場合、PHPは自動型変換（Coercion）のコストを毎回の関数呼び出しで支払うことになる。Union Typesを使用する場合は、必ず厳格な型宣言を併用し、Zend VMに無駄な変換コストを払わせないことが、ハイパフォーマンスWebシステムの鉄則である。
PHPエンジンの低レイヤを知る者にとって、言語機能の美しさは常にCPUサイクルとメモリという物理法則とのトレードオフの上に成り立っている。Union Typesを使いこなすとは、Zend VMのオペコード生成とJITの挙動を脳内で完全にシミュレートし、マシンにとって最も優しく、最も予測可能なコードを書き下ろすことに他ならない。