PHP 8.xにおける共用体（Union Types）の内部表現と型チェックのオーバーヘッド：Zend VMの深層
PHP 8の登場によって、言語の型システムは劇的な進化を遂げた。その中でも「共用体（Union Types）」の導入は、動的言語としての柔軟性を保ちつつ、静的解析の精度とコードの意図を明確にする上で画期的なマイルストーンであった。
しかし、エンジニアとして立ち止まって考えるべき本質的な問いがある。「この柔軟な型システムは、Zend VMの実行時において、どれほどの隠れた代償（オーバーヘッド）を支払わせているのか？」
ネット上の浅薄な解説記事では「PHP 8は速くなった」という抽象的な謳い文句ばかりが踊る。だが、我々は最高峰のWebシステムアーキテクトだ。Zend EngineのC言語による実装（`Zend/zend_types.h` や `Zend/zend_execute.c`）の低レイヤを剥ぎ取り、メモリ空間の構造体、オペコード（opcode）の生成メカニズム、そしてCPUキャッシュの挙動に至るまで、その全貌を解き明かさなければならない。
本稿では、Union Typesが実行時に引き起こす型チェックのオーバーヘッドの正体を、Zend VMの内部構造から徹底的に紐解く。
—
1. Zend VMにおける変数の物理表現：`zval` と型情報の密結合
PHPのすべての変数は、C言語レベルでは `zval`（Zend Value）という構造体としてヒープ、あるいはスタック上に存在する。PHP 8における `zval` のサイズは16バイトであり、これは64ビットアーキテクチャにおいて非常に美しく最適化されたサイズだ。
typedef struct _zval_struct {
zend_value value; // 8バイト:実際の値（数値、ポインタなど）
union {
uint32_t type_info; // 型情報と属性フラグ
// …
} u1;
union {
uint32_t next; // ハッシュ衝突時のチェインやGC用の情報
// …
} u2;
} zval;
PHPの変数は本質的に「タグ付き共用体（Tagged Union）」である。`type_info` には、それが整数の `IS_LONG` なのか、浮動小数点の `IS_DOUBLE` なのか、あるいはオブジェクトの `IS_OBJECT` なのかを示すタグが格納されている。
では、開発者が次のようなUnion Typeを定義したとき、Zend VMは何を行うのだろうか？
function process(int|string $data): void {
// 処理
}
このコードがパースされ、コンパイルされてオペコードに変換される際、型制約（Type Hint）は単なるメタデータとして捨てられるわけではない。実行時（Runtime）、関数呼び出しのたびに、あるいは代入のたびに、Zend VMはこの `type_info` と宣言されたUnionのビットマスクとの照合を強制される。
—
2. 型チェックのオーバーヘッド：単一型 vs Union型の実行時コスト
単一の型（例: `int $data`）であれば、Zend VMの型チェックは極めてシンプルだ。`Z_TYPE_P(val) == IS_LONG` という、CPUの1〜2クロックで完了する単一の条件分岐（あるいはビット演算）に帰結する。OPcacheが有効であれば、JITコンパイラはこの部分をネイティブの機械語（x86_64の `cmp` 命令等）に直接インライン展開することができる。
しかし、これが `int|string` のようなUnion Typeになった途端、内部の検証ロジックは複雑化する。
実行時チェッカーの内部挙動
Zend VMは、引数が渡された瞬間に以下の処理を行う：
1. 渡された `zval` の `type_info` を取得。
2. 宣言されたUnionの型ビットマスク（例: `Z_TYPE_BITMASK(IS_LONG) | Z_TYPE_BITMASK(IS_STRING)`）との論理積（AND）をとる。
3. マッチしない場合、かつ型安全性（strict_types）のコンテキストや自動型変換（Coercion）のルールに従い、許容される変換（例：文字列から整数への暗黙的変換）が可能かどうかの追加判定を実行する。
この「分岐の増加」と「ビットマスクの評価」は、マイクロベンチマークのレベルでは無視できないオーバーヘッドを生む。特に、高頻度で実行されるホットパス（Hot Path）内の小さな関数においてUnion Typeを多用すると、CPUの分岐予測（Branch Prediction）がミスしやすくなり、パイプラインハザードを引き起こす原因となる。
—
3. OPcacheプリローディングとJITにおける最適化の限界
PHP 8.xのJITコンパイラ（DynASMベース）は、型推論（Type Inference）が成功した場合に劇的な高速化をもたらす。しかし、Union Typeが指定された場合、JITの最適化器（Optimizer）にとって厄介な問題が生じる。
JITは「この変数は常にこの型である」という仮説（Guard）を立てることでネイティブコードを生成する。しかし、Union Typeは「複数の型を許容する」という設計思想そのものであるため、JIT生成される機械語は必然的にポリモーフィックなディスパッチ（型ごとの処理分岐）を含まなければならなくなる。
以下のコードを考えてみよう。
// 頻繁に呼び出されるホットパス関数
function calculate(int|float $value): float {
return $value 2.5;
}
この場合、JITは `$value` が `IS_LONG` の場合と `IS_DOUBLE` の場合の双方に対応するガードコードを生成するか、あるいは汎用的なCのランタイムヘルパー関数へ処理を委譲せざるを得なくなる。結果として、純粋な `float $value` に比べて、JITの恩恵（Native Machine Codeの純度）が薄れる傾向にある。
—
4. 極限のパフォーマンスチューニング：型チェックコストを相殺する設計
では、我々アーキテクトはこのオーバーヘッドをどのように克服すべきか？
セキュリティや保守性の観点からUnion Typesは強力な武器であるが、ミリ秒単位のレイテンシが命運を分ける高スループットなAPIやドメインロジックのコアにおいては、以下の原則に従うべきである。
① ホットパスでのUnionの排除とオーバーロード的設計
ループ内や高頻度で呼ばれる関数内での `int|string` のような広範なUnionは避け、必要であればメソッドを分割するか、静的な型に寄せる。
// 悪例：ループ内で毎回Unionの解決コストが発生する
foreach ($items as $item) {
processData($item); // int|string|array を受け取る重い関数
}
// 改善案：型ごとに処理をディスパッチしてからループを回す、あるいは型をあらかじめ統一する
$intItems = array_filter($items, ‘is_int’);
processIntItems($intItems);
② strict_types=1 の徹底による暗黙的変換コストの排除
`declare(strict_types=1);` を指定することで、Zend VMは実行時の複雑な型 coercion（暗黙の型変換ロジック）をスキップし、厳格なビットマスクの一致判定のみに最適化することができる。これはCPUサイクルを節約する上で極めて効果的だ。
—
5. 結びにかえて：エンジニアが掌握すべき「抽象化の代償」
PHP 8のUnion Typesは、開発者の認知負荷を下げ、バグを未然に防ぐための素晴らしい機能である。しかし、それは決して「無料（ゼロコスト）」ではない。
すべての言語機能の裏側には、Zend VMのメモリ管理、`zval` の型タグ、そしてCPUのクロックサイクルという厳格な物理法則が存在する。最高峰のエンジニアとは、その抽象化の美しさに酔いしれるだけでなく、その裏側にある「代償」を正確に計算し、システム全体のアーキテクチャをデザインできる者のことである。
コードを書くとき、その1行がZend Engine上でどう解釈され、CPUキャッシュにどう影響を与えるか——そのイメージを常に脳内に描くこと。それこそが、PHPを真に掌握する者の境地である。