PHP 8.x Union Typesの内部表現と実行時オーバーヘッド：Zend VMの深層と型安全の代償
PHP 8.0で導入されたUnion Types（共用体型）は、PHPDocに依存していた静的解析の時代を終わらせ、言語仕様レベルでの堅牢な型安全をもたらした。`int|string` や `User|null` といった表現は、開発者の認知負荷を下げ、IDEやStatic Analysis Tool（PHPStan, Psalmなど）との親和性を劇的に向上させた。
しかし、Webシステムアーキテクトの視点に立てば、言語仕様の美しさと「Zend VM（Zend Engine）の物理的な実行コスト」は常にトレードオフの関係にある。動的型付け言語として最適化されてきたPHPのランタイムにおいて、1つの変数やプロパティが複数の型を取り得るという事実、そして関数呼び出しやプロパティ代入のたびに発生する型解決は、内部でどのようなメモリ構造とオペコードの実行を引き起こしているのか。
本稿では、Zend VMのソースコードレベルでのデータ構造、オペコードの解決プロセス、そして極限のパフォーマンスを追求する現場において Union Types がもたらすオーバーヘッドの本質を解き明かす。
—
1. Zend Engineにおける変数の内部表現：`zval` と型情報
PHPのすべての変数は、C言語レベルでは `zval`（Zend Value）構造体として表現される。PHP 8における `zval` のサイズは16バイトであり、値本体を保持する8バイトの共用体（`zend_value`）と、型情報やGC（ガベージコレクション）のフラグを保持する8バイトのヘッダで構成されている。
// Zend/zend_types.h (概念的構造)
struct _zval_struct {
zend_value val; // 8バイト: 値 (zend_long, double, zend_string, zval, etc.)
union {
struct {
ZEND_ENDIAN_LOHI_4(
zend_uchar type, // 1バイト: 基本データ型 (IS_LONG, IS_STRING等)
zend_uchar type_flags, // 1バイト: メモリ管理・GCフラグ
zend_u16 gc_info // 2バイト: ガベージコレクション用情報
)
} v;
uint32_t type_info; // 4バイトの型情報一括処理用
} u1;
union {
uint32_t next;
uint32_t cache_slot;
uint32_t ptr_type;
} u2;
};
従来のPHP（単一型、あるいはスカラー型ヒント）において、実行時の型チェックは `Z_TYPE_P(zval)` を参照し、期待される基本型（例: `IS_LONG`）と一致するかを高速なC言語の条件分岐（あるいはジャンプテーブル）で判定するだけであった。
Union Typesが導入された場合の `zval` と AST / CE の関係
Union Typesが指定された場合、変数自体の `zval` が複数型を直接内包するわけではない。変数（`zval`）はあくまで単一の具象値（Concrete Value）を持ち、その値が「許可された型のいずれに該当するか」を検証する責任が、関数/メソッドのシグネチャ、またはプロパティ定義に付随する型情報（`zend_type`）側に発生する。
関数引数に `int|string` が指定された場合、Zend Engineはコンパイル時にその型情報を `zend_type` 構造体として構築し、関数エントリー（`zend_function`）のキャッシュスロットに保持する。
—
2. 実行時オーバーヘッドの正体：オペコードと型解決のコスト
Union Typesにおけるオーバーヘッドは、「メモリ上の `zval` の肥大化」ではなく、「実行時（Runtime）における型チェックの分岐コスト」にある。
次のようなコードを考えてみべきだ。
declare(strict_types=1);
function process(int|string $data): string {
return (string)$data;
}
for ($i = 0; $i < 1_000_000; $i++) {
process($i % 2 === 0 ? 42 : "foo");
}
このコードが実行される際、Zend VMは以下のステップを踏む。
1. 引数渡しのフェーズ: 関数呼び出し時（`DO_FCALL` 等のオペコード）、Zend VMは渡された `zval` の型が、宣言された `int|string` のいずれかに合致するかを検証する。
2. 型マスク（Type Mask）の評価: PHP 8の `zend_type` は、複数の型をビット演算用のマスク（Type Mask）として保持する。単一型であれば単なるビット比較で済むが、Union Typesの場合、許可されている複数の型フラグとのビット単位の論理和（OR）および一致判定が必要となる。
3. VMハンドラの分岐増加: 厳格な型付け（`strict_types=1`）が有効であっても、Union内に含まれる型の数だけ、VM内部の引数バインド処理における条件分岐（`if/else` または `switch`）のパスが増加する。
JITコンパイラ視点での影響
OPcacheのJITコンパイラ（DynASMを使用したマシンコード生成）が有効な場合、単一型であればCPUのネイティブなレジスタ操作と単一の型チェック（例: `cmp $IS_LONG, %reg`）にコンパイルされる。
しかし、Union Typesが絡むと、JIT生成されるマシンコードのパスが分岐するか、あるいは型解決のためのインラインキャッシュ（Type Inference Cache）がミスヒットしやすくなる。特に動的な型が頻繁に入れ替わる場合、JITコードはガード（Guard）失敗によるインタープリタへのフォールバック（Deoptimization）を引き起こし、結果としてパフォーマンスが劣化する。
—
3. ベンチマークと実測：スカラー型 vs Union Types
百聞は一見に如かず。以下の検証スクリプトを通じて、単一型とUnion Typesの実行速度の乖離を確認する。
singleInt(100);
}
$end = hrtime(true);
echo “Single Int: ” . (($end – $start) / 1e6) . ” ms\n”;
// 2. Union Typesの計測
$start = hrtime(true);
for ($i = 0; $i < $iterations; $i++) {
$bench->unionIntString(100);
}
$end = hrtime(true);
echo “Union Int|String: ” . (($end – $start) / 1e6) . ” ms\n”;
結果からの考察
このベンチマークをミリ秒単位で計測すると、`unionIntString` の方がわずかに関数呼び出しと型解決のオーバーヘッドにより実行時間が長くなることが確認できる（CPUアーキテクチャやJITの設定により変動するが、数%〜十数%の差が生じる）。
この差は、単発のリクエストであれば人間の知覚限界以下であるが、数万回のループや、高スループットが要求されるマイクロサービス、あるいはフレームワークのコアコンポーネント（DIコンテナやルーターなど）のホットパス（Hot Path）において蓄積されると、CPUサイクルの無駄な消費（キャッシュミスの増加）として表面化する。
—
4. アーキテクチャ設計における最適化戦略
では、Union Typesはパフォーマンスを低下させるため避けるべき機能なのだろうか？
答えは「No」である。PHP 8の設計思想は「開発者の生産性と静的解析の向上」に大きく舵を切っており、型安全性によるバグの未然防止の価値は、微小なCPUサイクルの損失を遥かに凌駕する。
しかし、極限のパフォーマンスが要求されるホットパスにおいては、以下のアーキテクチャ的配慮が必要となる。
1. ホットパスでのUnion Typesの排除
毎秒数万リクエストを処理するドメイン駆動設計（DDD）のエンティティ内部のゲッターや、シリアライザの内部ループ、パーサーなどのクリティカルなコードブロックでは、Union Types（例: `string|null` や `int|float`）の使用を避け、オーバーロード的なメソッド分離や、単一型への正規化を検討する。
// アンチパターン（ホットパス内）
public function getIdentifier(): int|string { … }
// 推奨アプローチ（型を明示的に分離）
public function getIntIdentifier(): int { … }
public function getStringIdentifier(): string { … }
2. DNF（Disjunctive Normal Form）Typesの罠
PHP 8.2で導入されたDNF Types（例: `(A&B)|C`）は、インターフェースの組み合わせによる柔軟性を爆発的に高めるが、Zend VMの型解決コストはさらに増大する。複雑な交差型と共用体の組み合わせは、ドメインモデルの境界（ControllerやFacade層）に限定し、データ処理の底層（Infra層やDomain Serviceの深部）へ持ち込まないことが、堅牢性と高速性を両立させる黄金律である。
—
5. まとめ
PHP 8.xのUnion Typesは、単なる「便利な構文糖衣」ではなく、Zend Engineの内部において `zend_type` マスクの拡張と、実行時型チェックの分岐増大を伴うアーキテクチャである。
そのオーバーヘッドは通常、ビジネスロジックの実行時間やI/O（DB、ネットワーク）のレイテンシにかき消されるため過剰に恐れる必要はない。しかし、Webシステムのアーキテクトとして、「どの言語機能がどのレベルのZend VMコストを生むか」を把握しているか否かは、大規模トラフィックに直面した際のボトルネック特定において決定的な差を生む。
型安全のメリットを最大限に享受しつつ、システム全体のパフォーマンスが限界を迎えたとき、低レイヤの知見こそが真の最適化の武器となる。