【PHPコア解剖】Zval構造体の変遷とメモリ領域の極致：Zend VMはいかにして型・参照カウントを超高速に処理するのか
「PHPは動的型付け言語だからメモリ効率が悪い」「参照渡し（`&`）を使えばメモリが節約できる」——もしあなたのチームのエンジニアがコードレビューでこのような発言をしていたら、今すぐその認識を改めさせる必要があります。
現代のPHP（PHP 7以降、およびPHP 8.x）において、Zend Engineの内部実装は劇的な進化を遂げました。特に、すべての変数の根幹をなす `zval`（Zend Value）構造体 の再設計は、CPUのL1/L2キャッシュラインを意識した極限のメモリ配置と型アクセスの高速化を実現しています。
本稿では、Zend VMの低レイヤ視点から`zval`構造体の内部メモリレイアウト、型情報（`type`）および参照カウント（`refcount`）の真の格納場所、そしてZend VMがこれらをどのようにアクセス・最適化しているかを徹底解剖します。実務におけるメモリリークを防ぎ、アプリケーションの限界性能を引き出すための確固たる知見を習得してください。
—
1. PHP 5からの脱却：16バイトへと削ぎ落とされた `zval` の正体
PHP 5時代の`zval`は、ヒープ領域（`emalloc`）に動的に確保される24〜32バイトの巨大な構造体であり、すべての変数へのアクセスはポインタの二重間接参照（Double Indirection）を伴っていました。これが大量のメモリ断片化とキャッシュミスを誘発していたのです。
PHP 7以降、Zend Engineはこの設計を根本から覆しました。現在の `zval` は 厳密に16バイト（64bit環境）にアラインメント され、原則としてスタック領域や配列の連続したメモリブロック内に「直接埋め込み（Inlined）」で配置されます。
C言語レベルに見る `zval` の構造（Zend Engine）
struct _zval_struct {
zend_value value; / 8バイト: 値本体またはデータ構造へのポインタ /
union {
struct {
ZEND_ENDIAN_LOHI_4(
uint8_t type, / 1バイト: 型情報 (IS_STRING, IS_ARRAY等) /
uint8_t type_flags, / 1バイト: 型の属性フラグ (IS_TYPE_REFCOUNTED等) /
uint16_t call_info / 2バイト: VM内部のコンテキスト情報 /
)
} v;
uint32_t type_info; / 4バイト: ビット演算で一括アクセスするための結合体 /
} u1;
union {
uint32_t next; / 4バイト: HashTableでのハッシュ衝突チェイン用インデックス /
/ その他の内部用途 /
} u2;
}; / 合計: 8 + 4 + 4 = 16バイト /
メモリレイアウトの特長
1. `zend_value` (8バイト):
スカラー型（`long`, `double`, `bool`）の場合は、ポインタを辿ることなくこの8バイトの中に生の数値データが直接格納されます。
2. `u1` (4バイト):
`type` や `type_flags` が配置されます。Zend VMは `type_info` という32ビット整数としてこれにアクセスし、1回のビットマスク操作（Bitwise AND）で型チェックとフラグ判定を判定完了させます。
3. `u2` (4バイト):
主に配列（`HashTable`）のバケット構造体として埋め込まれた際、ハッシュ衝突時の次の要素へのインデックス等を保持するために利用されます。
—
2. 参照カウント（`refcount`）はどこへ消えたのか？
旧来のPHPを知る開発者が最も混乱するのが、「`zval` 構造体の中に `refcount` フィールドが存在しない」という事実です。
「では、ガベージコレクション（GC）や参照カウントはどこで管理されているのか？」
答えは、「値（Value）側」です。
リファレンスカウントを持つ型と持たない型
16バイトの`zval`自体はコピーが非常に高速（単なるCPUレジスタ経由の16バイト転送）であるため、スカラー値に対して参照カウントを管理する必要性は皆無です。そのため、PHP 8のZend Engineでは、データ型を以下の2種類に明確に分離しました。
| 分類 | 対象型 | `refcount` の有無 | メモリ格納先 |
| :— | :— | :— | :— |
| Non-Refcounted | `null`, `bool`, `long`, `double`, インターン化文字列, 不変配列 | なし | `zval.value` に直接埋め込み（または静的領域） |
| Refcounted | 通常文字列, 配列, オブジェクト, リソース, 明示的参照（`zend_reference`） | あり | ポインタ先のヘッダ（`zend_refcounted_h`） |
`Refcounted` なオブジェクト（例: `zend_string`, `zend_array`, `zend_object`）は、その構造体の先頭に必ず共通のヘッダ領域 `zend_refcounted_h` を保持しています。
typedef struct _zend_refcounted_h {
uint32_t refcount; / 4バイト: 参照カウンタ /
union {
struct {
ZEND_ENDIAN_LOHI_3(
uint8_t type,
uint8_t flags,
uint16_t gc_info / GCのルートバッファインデックス /
)
} v;
uint32_t type_info;
} u;
} zend_refcounted_h;
Zend VMは、`zval.u1.type_flags` に `IS_TYPE_REFCOUNTED` ビットが立っている場合のみ、`zval.value` のポインタを辿り、その先頭にある `refcount` を加減算します。
—
3. 明示的参照（`&$var`）と Copy-on-Write (CoW) のメカニズム
実務のコードレビューで最も正すべき誤解が、「巨大な配列を関数に渡すときは参照渡し（`&$array`）にした方がメモリを節約できる」という神話です。現代のPHPにおいて、これは完全に間違いであり、むしろパフォーマンスを低下させます。
Copy-on-Write (CoW) の正常な挙動
PHPの配列は、デフォルトで Copy-on-Write（書き込み時ディープコピー）という最適化が働きます。
1. 関数に `$array` を値渡しした時点では、内部の `zend_array` の `refcount` が `1` 増えるだけで、配列要素のメモリコピーは1バイトも発生しません。
2. 関数内で配列が変更（Write）された瞬間に初めて、Zend VMは `refcount > 1` であることを検知し、配列構造体を複製（分離: Separation）します。
参照（`&$var`）を明示した場合の内部破壊
明示的な参照演算子 `&` を使用すると、Zend VMは `zval` の型を `IS_REFERENCE` に変更し、ヒープ上に `zend_reference` 構造体を別途割り当てます。
[zval A ($a)] —> [zend_reference] —> [zend_array (配列データ)]
^
[zval B ($b)] ——–|
これにより、Zend VMが本来行うはずの「連続したメモリ空間での高速な処理」が阻害され、ポインタの参照追跡のオーバーヘッドおよびメモリ割り当ての負荷が増大します。
—
4. 実務で差がつく：メモリ挙動とGCを検証する検証コード
以下のスクリプトは、Zend VM内部の参照カウント・Copy-on-Write・明示的参照がメモリ使用量にどのような影響を与えるかを可視化する実用的な検証プログラムです。
/
final class MemoryMechanicsProfiler
{
/
- 現在のメモリ使用量（バイト）を取得
/
private static function getMemoryUsage(): int
{
// メモリ空間の正確な増減を測るため、ガベージコレクタを意図的に起動
gc_collect_cycles();
return memory_get_usage();
}
/
- Copy-on-Write (CoW) の挙動証明
/
public static function profileCopyOnWrite(): void
{
echo “=== 1. Copy-on-Write (CoW) の挙動検証 ===” . PHP_EOL;
$baseMemory = self::getMemoryUsage();
// 10万要素を持つ大きな配列を作成 (IS_ARRAY, Refcounted)
$originalArray = range(1, 100000);
$afterAllocMemory = self::getMemoryUsage();
echo sprintf(“配列生成後のメモリ消費: %d KB” . PHP_EOL, ($afterAllocMemory – $baseMemory) / 1024);
// 値渡しで別の変数に代入
// 内部的には zval の 16バイトがコピーされ、zend_array の refcount が 2 になるだけ
$copiedArray = $originalArray;
$afterCopyMemory = self::getMemoryUsage();
echo sprintf(“値代入直後のメモリ増減: %d バイト (メモリ領域は共有されている)” . PHP_EOL, $afterCopyMemory – $afterAllocMemory);
// 代入側を変更（Writeを発生させる）
// ここで refcount > 1 を検知し、Zend VMが zend_array の分離(Separation)を実行
$copiedArray[0] = 99999;
$afterWriteMemory = self::getMemoryUsage();
echo sprintf(“値変更（CoW発動）後のメモリ増加: %d KB (ディープコピーが発生)” . PHP_EOL, ($afterWriteMemory – $afterCopyMemory) / 1024);
unset($originalArray, $copiedArray);
echo PHP_EOL;
}
/
- 明示的参照 (&$var) による内部オーバーヘッドの検証
/
public static function profileExplicitReference(): void
{
echo “=== 2. 明示的参照 (&$var) のオーバーヘッド検証 ===” . PHP_EOL;
$baseMemory = self::getMemoryUsage();
// 巨大なデータ構造を用意
$data = range(1, 100000);
$beforeRefMemory = self::getMemoryUsage();
// 明示的参照を使用する関数に引き渡す処理のシミュレーション
$refTarget = &$data; // zend_reference 構造体の割り当てが発生
$afterRefMemory = self::getMemoryUsage();
echo sprintf(“明示的参照作成による追加メモリ消費: %d バイト (zend_reference構造体の生成)” . PHP_EOL, $afterRefMemory – $beforeRefMemory);
// 参照を解除しないままルーズに使用し続けると、CoWが無効化され予想外の変異が発生するリスクを負う
unset($data, $refTarget);
echo PHP_EOL;
}
/
- 循環参照とガベージコレクション（GC）Root Bufferの挙動
/
public static function profileCircularReference(): void
{
echo “=== 3. 循環参照によるメモリリークのリスク検証 ===” . PHP_EOL;
$baseMemory = self::getMemoryUsage();
// GCを意図的に無効化して挙動を確認
gc_disable();
for ($i = 0; $i < 10000; $i++) {
$parent = new stdClass();
$child = new stdClass();
// 循環参照の構築
$parent->child = $child;
$child->parent = $parent;
// スコープを抜けるため、parent/child の zval は破棄される。
// しかし、内部の zend_object はお互いを参照し合っているため refcount が 1 のまま残る。
unset($parent, $child);
}
$leakMemory = self::getMemoryUsage();
echo sprintf(“GC停止時の循環参照によるメモリリーク量: %d KB” . PHP_EOL, ($leakMemory – $baseMemory) / 1024);
// 明示的にGCを実行してルートバッファから循環参照を回収
$collectedCycles = gc_collect_cycles();
$afterGcMemory = self::getMemoryUsage();
echo sprintf(“GC実行により回収されたサイクル数: %d” . PHP_EOL, $collectedCycles);
echo sprintf(“GC実行後のメモリ解放量: %d KB” . PHP_EOL, ($leakMemory – $afterGcMemory) / 1024);
gc_enable(); // GCを再有効化
}
}
// プロファイラーの実行
MemoryMechanicsProfiler::profileCopyOnWrite();
MemoryMechanicsProfiler::profileExplicitReference();
MemoryMechanicsProfiler::profileCircularReference();
—
5. テクニカルリードが押さえるべき「堅牢な設計ルール」
Zend Engineの内部構造を踏まえ、本番環境のWebシステムやAPI構築、バッチ処理においてチームへ徹底させるべき3つの設計原則をまとめます。
原則1：引数の「参照渡し（`&$arg`）」は原則禁止
特別かつ明確な意図（例: 大量データを扱う関数の内部で引数を直接書き換えて呼び出し元に返す設計だが、返り値のコストすら嫌う極限のケース）がない限り、参照渡しは禁止とします。
- 理由: PHPのCopy-on-Write（CoW）最適化を壊し、`zend_reference` の生成によるメモリオーバーヘッドを生むため。配列やオブジェクトの受け渡しは「値渡し」で記述するのが最も安全かつ高速です。
原則2：バッチ処理・デーモンプロセス（Swoole/RoadRunner等）における循環参照の明示的断絶
PHP-FPMのような「1リクエスト1プロセス破棄」のアーキテクチャでは、リクエスト終了時にプロセスのメモリ空間全体がリセットされるため、軽微なメモリリークは隠蔽されます。
しかし、長期間生存する常駐型ワーカー（RoadRunner, Swoole, Queue Worker）では、オブジェクト同士の循環参照がGCルートバッファ（デフォルトで10,000要素）を即座に溢れさせ、深刻なパフォーマンス低下とOOM（Out of Memory）を引き起こします。
- 対策: 長寿命のオブジェクトツリーを解体する際は、デストラクタ（`__destruct`）や明示的な `cleanUp()` メソッドを用意し、相互参照に `null` を代入して参照カウントを確実に `0` へ落としてください。
原則3：大量データのイテレーションには「ジェネレータ（Generator）」を活用する
DBから数万件のレコードを取得して加工する際、巨大な配列（`zend_array`）を構築すると、要素数分の `zval` (16バイト) と `Bucket` 構造体 (32バイト)、文字列キーの `zend_string` が一気にヒープを圧迫します。
- 対策: `yield` を用いた Generator を使用すれば、同時にメモリ上に存在する `zval` は常に1要素分に限定されます。Zend VMのスタックフレームが維持され、メモリ消費量はほぼフラット（O(1)）に保たれます。
—
まとめ
PHPの内部エンジンであるZend VMは、16バイトの `zval` 構造体と `zend_refcounted_h` の見事な分離によって、L1/L2キャッシュ効率を高め、動的型付け言語とは思えないパフォーマンスを叩き出しています。
1. `zval` は16バイトであり、スカラー値は直埋めされる。
2. `refcount` は `zval` ではなく、ポインタ先のオブジェクトヘッダに存在する。
3. CoWが存在するため、安易な参照渡し（`&`）は性能劣化の元になる。
この低レイヤのメカニズムを脳内に描いてコードを書くこと。それこそが、単に「動くコード」を書くプログラマと、大規模システムを支える「真のシステムアーキテクト」を分かつ決定的な差なのです。