PHP 8配列の深層：HashTableの衝突とPacked Array最適化の物理構造
PHPにおける`array`は、言語仕様上の万能データ構造である。それは連想配列であり、順序付きマップであり、リストであり、スタックであり、キューでもある。この異様なまでの柔軟性を支えているのが、Zend Engine（Zend VM）の根幹をなす`HashTable`構造体である。
しかし、この「何でも入る」という美徳は、高トラフィックなWebアプリケーションにおいてメモリ効率とCPUキャッシュ効率の観点から最大のボトルネックとなり得た。PHP 7でのZendArrayの刷新により劇的な省メモリ化と高速化が達成されたが、PHP 8世代における配列の最適化、特に「Packed Array（密集配列）」への昇格メカニズムの理解は、数百万リクエストを捌くバックエンドシステムの設計において不可欠な前提知識である。
本稿では、Zend VMのC言語レベルのソースコード（Zend Engine）の挙動に踏み込み、HashTableがどのような条件でPacked Arrayへと姿を変え、メモリ空間とCPUキャッシュを制圧するのか、その低レイヤの真実を解き明かす。
—
1. Zend EngineにおけるHashTableの基本構造と代償
PHPの配列は、抽象データ型としては`zval`（Zend Value）のハッシュテーブルである。Cのソースコード上では、これは`Bucket`構造体の配列と、ハッシュ値からBucketのインデックスを引くためのインデックス配列（マッピングテーブル）によって構成されている。
// zend.h (概念的な構造の模倣)
typedef struct _bucket {
zval val; // 格納される値（zval構造体）
zend_ulong h; // ハッシュ値（整数キー、または文字列のハッシュ）
zend_string key; // 文字列キー（数値キーの場合はNULL）
} Bucket;
typedef struct _zend_array {
zend_refcounted_h gc;
union {
struct {
zend_uchar flags;
zend_uchar nApplyCount;
zend_uchar nIteratorsCount;
zend_uchar consistency;
} v;
uint32_t flags;
} u;
uint32_t nTableMask; // ハッシュマスク（負数）
Bucket arData; // Bucket配列の実体（メモリ上の連続領域）
uint32_t nNumUsed; // 使用済みBucket数
uint32_t nNumOfElements; // 有効な要素数
uint32_t nTableSize; // ハッシュテーブルのサイズ（2のべき乗）
zend_internal_dtl pDestructor;
int32_t h; // 内部ポインタ用など
} zend_array;
通常の連想配列では、文字列キーや順序がバラバラの数値キーが混在するため、ハッシュ衝突（Collision）を回避するための計算や、`arData`上のポインタジャンプが発生する。CPUのL1/L2キャッシュミスを引き起こしやすく、これが大規模な配列走査における隠れた性能劣化要因となる。
—
2. Packed Array（密集配列）への昇格条件と内部挙動
PHP 8（およびPHP 7以降）のZend Engineは、配列が「単なる連番の数値インデックスのリスト」である場合、無駄なハッシュ計算やインデックスマッピングを完全にバイパスする最適化機構を備えている。これがPacked Array（PACKEDフラグが立った配列）である。
昇格の絶対条件
配列が通常の`HashTable`から`Packed Array`へ昇格、あるいは最初からその形態で初期化されるためには、以下の条件を厳密に満たす必要がある。
1. キーが純粋な数値インデックスであること：文字列キーが1つでも混入してはならない。
2. キーが `0` から始まり、連続していること：`[0, 1, 2, 3]` のような密な状態である必要がある。途中に欠番（例: `0`の次に`2`が来る）があったり、逆順・ランダムな順序で代入された場合は、Packed Arrayの要件を満たさないため通常のHashTableにフォールバック（あるいは最初から構築）される。
メモリ上の変化
Packed Arrayとして最適化された状態では、`arData`が指すメモリ領域には、ハッシュ衝突を解決するためのマッピングテーブルや複雑なハッシュ計算のオーバーヘッドが存在しない。実質的にC言語の「ただの配列（Flat Array）」と同じ構造になり、`zval`が一直線に並ぶ。
これにより以下のメリットが生まれる。
- メモリフットプリントの極小化：余計なハッシュ関連のメタデータやポインタが省かれる。
- CPUキャッシュのヒット率向上：連続したメモリアドレスにデータが配置されるため、プリフェッチが極限まで効率化される。
—
3. 実コードによるメモリ挙動の検証とアンチパターン
次のPHPコードを見てほしい。開発者が無意識に書くコードが、いかにしてZend Engineの最適化を破壊し、メモリ消費を肥大化させるかの典型例である。
/
// ケースA: 純粋なPacked Arrayとして生成される理想的な初期化
$packedArray = [];
for ($i = 0; $i < 10000; $i++) {
$packedArray[] = $i; // 0から順にインデックスが割り当てられる
}
// この時点で $packedArray は内部的に ZEND_HASH_APPLY_PROTECTION | HASH_FLAG_PACKED などの
// 最適化フラグを持ち、極めて高効率なメモリ配置となっている。
// ケースB: 途中のインデックスをスキップ、あるいは文字列キーを混入させる悪夢
$inefficientArray = [];
for ($i = 0; $i < 10000; $i++) {
// 偶数インデックスのみを格納（間に欠番が発生する）
$inefficientArray[$i 2] = $i;
}
// または途中で文字列キーを代入する
$inefficientArray['meta'] = 'danger';
// この瞬間、Zend Engineは内部でハッシュテーブルへの構造変換（降格）を実行する。
// arDataの再割り当て、ハッシュ関数の適用、衝突解決のためのポインタ調整が発生し、
// CPUサイクルとメモリ領域が余分に消費される。
内部構造のトレース（GDBやZend拡張による観測視点）
Cレベルのデバッガー（GDB）を用いてZend VMの実行中に`zval`の構造を覗くと、Packed Arrayのフラグが落ちた瞬間に `GC` や `u.v.flags` のビットマスクが変化し、`nTableMask` が有効化されてハッシュ解決モードに移行する様子が確認できる。
高スループットなAPIレスポンスの構築や、数万件のレコードをメモリ上で処理するバッチ処理において、ループの初期化順序やキーの指定方法を誤るだけで、PHPプロセスのRSS（Resident Set Size）が跳ね上がり、OOM（Out of Memory）のリスクやGC（ガベージコレクション）の走査コスト増大を招く。
—
4. 高速化・メモリ効率最大化のためのアーキテクチャ設計指針
PHP 8環境で極限のパフォーマンスを引き出すためには、Zend Engineのメモリ管理モデルに逆らわないデータ構造の設計が求められる。
1. 配列の構築は「常にゼロからの連番プッシュ」で行う
要素を動的に追加する場合は、キーを明示的に指定せず `$array[] = $value` 構文を使用する。これにより、PHP内部のコンパイラおよびVMは可能な限りPacked Arrayとしての構築を維持・最適化する。
2. 大規模データにはSPL（Standard PHP Library）やFFIの検討
もし数百万件単位の数値を扱うのであれば、PHPの`array`（HashTable）の枠組みを超えた設計が必要になる。
- `SplFixedArray`：固定長のC風配列であり、HashTableのオーバーヘッドを完全に排除する。ただし、動的な拡張ができないトレードオフがある。
- `FFI` (Foreign Function Interface)：PHP 8の強力な武器。C言語側のメモリ領域（`1D malloc`された連続メモリ）を直接操作することで、Zend Engineの`zval`管理すらバイパスした超高速な数値計算・データ処理が可能となる。
create_int_array(1000000);
// … 高速な並行処理・数値演算 …
$ffi->free_int_array($c_array);
—
5. まとめ
PHP 8の配列は、かつての「遅くて重い汎用ハッシュマップ」という汚名を返上し、Zend Engineの徹底的な低レイヤ最適化によって洗練されたデータ構造へと進化を遂げた。しかし、その恩恵を最大限に受けるためのルール――すなわち「Packed Arrayの条件を破壊しないこと」――を破れば、エンジンは容赦なく重いHashTableの処理コストを突きつけてくる。
Webシステムアーキテクトとして、我々はフレームワークが提供する抽象化の裏側にあるZend VMのメモリ空間の息吹を感じ取らなければならない。1リクエストあたりのメモリ消費の数バイト、数キロバイトの無駄を削ぎ落とすことこそが、数万QPSを耐え抜く堅牢なインフラストラクチャを構築唯一の王道なのである。