Zend VMの解剖学：PHP 8 Union/Intersection Typesの実行時型解決コストとオペコード最適化の真実
PHP 8以降、私たちは`int|string`や`Countable&Iterator`といった豊かな型システムを手に入れた。静的解析の精度は飛躍的に向上し、IDEの補完は神がかり的な領域に達している。
だが、チーフアーキテクトとして問いたい。
「その美しい型定義は、Zend VMの実行サイクルにおいてどれほどのコストを支払わせているか？」を意識したことがあるだろうか。
PHPは「スクリプト言語」という名の、C言語で書かれた動的仮想マシンである。私たちが書いたコードは、Zend VMのオペコード（Opcode）にコンパイルされ、CPUのキャッシュラインを揺らしながら実行される。Union TypesやIntersection Typesは、単なるドキュメントではない。実行時にZend VMの型チェッカーを直撃する、動的なアサーションの嵐なのだ。
本稿では、PHP 8.xの複合型が内部のZend VM上でどのように展開され、どのようなオーバーヘッドを生むのか、そしてOPcacheがそれをどう最適化するのかを、低レイヤのメモリ構造から徹底的に解剖する。
—
1. Zend VMにおける型チェックのプリミティブ：`zend_execute_data`とオペコード
PHPの実行単位は、`zend_execute_data`構造体によって管理される。関数呼び出しやメソッド実行のたびにスタックフレームが積まれ、Zend VMはこのコンテキスト上でオペコードを順次ディスパッチしていく。
従来のPHP 7系におけるスカラ型やクラス型（`int`, `string`, `ClassName`等）の型チェックは、Zend VMのオペコードレベルで非常にシンプルだった。例えば、引数の型チェックは `ZEND_RECV_INIT` や、型hint情報を伴う専用のハンドラによって、Cレベルのビットマスク判定（`Z_TYPE_P`の比較など）で瞬時に終わっていた。
しかし、PHP 8のUnion Types（`A|B`）およびIntersection Types（`A&B`）が登場したことで、型チェックの計算量は単純なO(1)のビット判定から、分岐を含む評価ロジックへと変貌した。
複合型が生成するオペコードの現実
次のような、Union Typeを持つ関数を考えてみよう。
declare(strict_types=1);
function process(int|string|null $data): void {
// 処理本体
}
process(42);
このコードがコンパイルされるとき、Zend VMは単一の型フラグではなく、型アサーションのリスト（Type List）をメソッドまたは関数のエントリー情報（`zend_function`構造体の`arg_info`）に保持する。
JIT（Just-In-Time Compiler）が無効な環境、あるいは通常のOpcache実行時において、Zend VMはこの`int|string|null`を検証するために、以下のステップを踏む。
1. 渡されたzval（値のコンテナ）の型タグ（`u1.v.type`）を読み取る。
2. それが `IS_LONG`（int）か判定。一致すれば合格。
3. 一致しなければ、`IS_STRING`か判定。一致すれば合格。
4. 一致しなければ、`IS_NULL`か判定。一致すれば合格。
5. すべて不一致なら、`TypeError`（例外）をスローする。
つまり、Union Typesの右側に記述された型の数だけ、最悪ケースでの分岐コスト（Branch Mispredictionのリスク含む）が増加する。特にループ内で頻繁に呼び出される小さな関数において、この動的型解決のオーバーヘッドは無視できないボトルネックとなり得る。
—
2. Intersection Types（交差型）の残酷なコスト
Union Typesが「OR（どれか一つ）」であるのに対し、PHP 8.1で導入されたIntersection Types（`A&B`）は「AND（すべてを満たす）」である。これはオブジェクト指向の文脈において、さらに重い処理をZend VMに強いる。
interface LoggerAware { public function setLogger(Logger $logger): void; }
interface Auditable { public function getAuditId(): string; }
function handle(LoggerAware&Auditable $entity): void {
// …
}
このコードを実行するとき、Zend VMは単なるプリミティブ型の判定ではなく、オブジェクトの継承ツリーおよび実装インターフェースのハッシュテーブル走査を行わなければならない。
内部的には、PHPのオブジェクトは`zend_object`構造体を持ち、その中にクラスエントリー（`zend_class_entry`）へのポインタが含まれている。クラスエントリーは、自身が実装しているすべてのインターフェースのリストをキャッシュしているが、Intersection Typesの検証では、指定されたすべてのインターフェース（この場合は`LoggerAware`と`Auditable`の両方）をオブジェクトが完全に包含しているかを、実行時にアサートする必要がある。
キャッシュの効かない動的解決とOPcacheの限界
ここでOPcacheの役割が重要になる。OPcacheはスクリプトのパース結果とオペコードを共有メモリ（SHM）にキャッシュし、パースやコンパイルのオーバーヘッドをゼロにする。
しかし、「型が何であるか」の解決（特にクラス名やインターフェース名を含む複合型）は、クラスのロード順序（Class Loading Order）やオートローダーの介入に依存する。
OPcacheのプリローディング（Preloading）機能を使用すると、起動時にすべてのクラスをメモリ上にロードし、クラスエントリー間の依存関係やインターフェースの実装関係をあらかじめ解決（Linking）しておくことができる。
; php.iniでのOPcacheプリローディング設定例
opcache.enable=1
opcache.memory_consumption=512
opcache.preload=/var/www/html/config/preload.php
もしプリローディングを行わずに複雑なIntersection Typesを多用した場合、Zend VMは初回の実行時にオートローダーを走らせ、クラス構造を解決するためのシンボルルックアップをグローバルなクラス表（EG(class_table)）に対して行う。この時、HashTableの衝突やロック競合が発生し、マルチプロセス（PHP-FPM）環境下ではスループットの低下を招く。
—
3. ベンチマークと実測：型定義の数とパフォーマンスの相関
理論だけでなく、実務上のリスクを証明しよう。以下のスクリプトを考えてほしい。
4. セキュリティ・アーキテクチャの視点：型システムの隙をつく攻撃ベクター
最高峰のアーキテクトであれば、パフォーマンスだけでなくセキュリティの文脈も忘れない。
PHP 8の厳密な型システム（`declare(strict_types=1);`）は、型安全性（Type Safety）を担保し、かつての「マジッククォートや緩やかな比較（`==`）に起因する脆弱性」を激減させた。しかし、型システムが複雑化（Union/Intersection化）することで、オブジェクトインジェクション（Object Injection）やガジェットチェーン（Gadget Chain）の構築における「型のすり抜け」が新たな研究対象となっている。
オブジェクトインジェクションと型アサーションの罠
攻撃者が `unserialize()` を通じて任意のオブジェクトを注入し、既存のコードベースのデストラクタやマジックメソッド（`__destruct`, `__toString`など）をハイジャックする脆弱性が発見されたとする。
開発者が次のようなコードを書いている場合：
class SessionManager {
public function __destruct() {
// 危険な操作：LoggerInterfaceまたはStringableを期待しているが…
$this->log->write(“Session closed”);
}
}
もし `$this->log` の型が `LoggerInterface|string` のようなUnion Typeであった場合、Zend VMの逆直列化（unserialize）プロセスにおいて、指定された型制約を満たす悪意あるオブジェクト（ガジェット）がインスタンス化され、予期せぬメソッド呼び出しを引き起こす可能性の窓が広がる。
防御の鉄則は明快だ：
1. 不必要なUnion Typesを避ける：特にパブリックなインターフェースや、外部入力を直接受け取る境界では、型を極力シンプル（単一の明確な型、あるいは限定されたValue Object）に保つ。
2. strict_typesの徹底：すべてのファイルで `declare(strict_types=1);` を強制し、暗黙の型変換（Coercive mode）によるZend VMの曖昧な挙動を完全に排除する。
3. OPcache Preloadingの活用：本番環境では必ずOPcacheプリローディングを有効化し、クラスの動的なロードに起因するタイミング攻撃や予期せぬ挙動を防ぐ。
—
結び：コードの美しさと低レイヤの現実の調和
Union TypesやIntersection Typesは、PHPを「大人のプログラミング言語」へと押し上げた素晴らしい機能である。しかし、私たちが書いたコードは最終的にC言語の仮想マシン上で実行される冷徹な現実を忘れてはならない。
「型を書けば書ほど安全で速くなる」という幻想を捨てよ。
真に高可用で、極限までチューニングされたWebシステムを構築するためには、言語機能の背後にあるZend VMの挙動、メモリ消費、そしてオペコードの鼓動を感じ取らなければならない。
型は道具であって、目的ではない。低レイヤを掌握した者だけが、PHPの限界を突破する真のシステムを設計できる。