PHP配列という名のパンドラの箱：なぜ我々は`vec`, `dict`, `keyset`へ魂を売らねばならないのか
HHVM（HipHop Virtual Machine）のアーキテクチャ設計およびHack言語のコア開発に長年携わってきた私にとって、PHPのレガシーな `array` 型ほど、システムの予測可能性とパフォーマンスを根底から破壊する「癌」はない。
PHPの `array` は、順序付きハッシュマップであり、ベクタであり、セットであり、その実態は動的かつ多態的なハッシュテーブル（`MixedArray` または `ApcFile` の残滓）である。この「何でも入るゴミ箱」構造は、プロトタイピングには魅力的かもしれないが、数百万行規模のコードベースにおいて、コンパイラの最適化を完全に殺し、実行時例外という名の地雷原を作り出す。
本稿では、PHPの配列からHackの厳格なコレクション型（`vec`, `dict`, `keyset`）への移行が、単なる「型アノテーションのお遊び」ではなく、HHVMのJITコンパイラ、メモリ管理、そして静的型チェッカーの鉄の意志とどのように結びついているのかを、低レイヤの視点から徹底的に解剖する。
—
1. 内部構造の崩壊：なぜPHPの `array` はJITの敵なのか
HHVMのネイティブ実行において、最も避けるべきアンチパターンは「型の多態性（Polymorphism）」の爆発だ。
PHPの `array` を使うとき、開発者は知らず知らずのうちに以下のような魔窟を作り上げている。
// PHPのレガシーな配列（何でも入る危険な混合構造）
$data = [
‘id’ => 42, // int
‘name’ => ‘Hack’, // string
0 => [1, 2, 3], // 内部配列
];
HHVMのJIT（HipHop JIT）は、トレースベースの最適化を行い、変数の型が静的に確定している場合にのみ、ネイティブのレジスタ操作やインラインキャッシュを生成する。しかし、キーが整数であったり文字列であったり、値の型が混在するPHPの `array` が現れた瞬間、JITは諦めざるを得なくなる。
結果として何が起きるか？
- ハッシュ計算のオーバーヘッド: 配列アクセスのたびに、キーのハッシュ値計算と型チェック（整数か文字列か）が走る。
- ポインタの不連続性: 値がヒープ上に散らばり、CPUキャッシュヒット率（Cache Locality）が劇的に低下する。
- メモリフットプリントの肥大化: 各要素が `TypedValue` 構造体（型タグ＋64bit値）のオーバーヘッドを抱え、さらにハッシュテーブルの衝突解決用ポインタがメモリを食い潰す。
これに対し、Hackが提供する `vec`, `dict`, `keyset` は、メモリレイアウトの物理的な最適化を前提に設計されている。
—
2. Hackコレクション三銃士の物理メモリレイアウト
Hackの `strict` モード（``vec` （連続ベクタ）
- 構造: C++の `std::vector` や Rustの `Vec` に類似。
- メモリ: キーは暗黙の `0` から始まる連続した整数のみ。内部的には連続したメモリ領域に値が並ぶ。
- 最適化: ハッシュ計算が完全に排除され、O(1) のインデックスアクセスは単なるポインタのオフセット演算に還元される。CPUキャッシュの恩恵を最大限に受ける。
`dict` （厳格な連想配列）
- 構造: キーの型（`arraykey` = `int` または `string`）と値の型が静的に保証されたハッシュマップ。
- メモリ: PHPの `array` とは異なり、型が均一であるため、HHVMは特定のハッシュアルゴリズムやストレージレイアウト（Compact Arrayなど）をアグレッシブに適用できる。
`keyset` （一意な集合）
- 構造: 値がそのままキーとなり、重複を許さない集合。
- メモリ: データベースのインデックスと同様のO(1) メンバーシップテスト（`C\contains`）を提供。無駄なバリュー領域を持たないため、メモリ効率が極めて高い。
—
3. 実践：PHP配列からHackコレクションへの移行と型チェッカーの防壁
実際のコードベースで、どのようにこの移行を行い、型チェッカーがどのようにシステムを守るのかを見ていこう。
以下のコードは、`strict` モードにおけるユーザー情報の処理パイプラインである。
int,
‘name’ => string,
‘roles’ => vec
);
class UserProcessor {
/
- PHPの曖昧な配列を受け取らず、厳格な dict と vec を処理する。
/
public function processUsers(dict
// keyset を使って重複のない権限リストをO(1)で構築
varray
foreach ($users as $id => $user) {
// 静的型チェッカーが $user[‘id’] が int であることを保証しているため、
// 実行時型チェックのオーバーヘッドはゼロ。
if ($user[‘id’] <= 0) {
throw new \InvalidArgumentException("Invalid user ID: {$id}");
}
foreach ($user['roles'] as $role) {
// keyset への追加は自動的に重複を排除する
$all_roles[] = $role; // Hackのkeyset/vecへの要素追加構文
}
}
return $all_roles;
}
}
このコードがシニアエンジニアにとって美しい理由
1. 型チェッカー（hhvm-compiler / Hack Typechecker）の事前検証:
もし開発者がうっかり `$user[‘roles’]` に文字列ではなく数値を混入させようとしたり、存在しないキーにアクセスしようとした場合、実行時ではなくエディタ上（CI/CDパイプライン）で即座にビルドが失敗する。本番環境で `Undefined index` や `TypeError` が爆発する未来が、数学的に予防される。
2. ランタイムの最適化パス:
`dict
—
4. 移行戦略：レガシーPHP配列を駆逐するためのハードルール
大規模なPHPコードベースをHackの厳格なコレクションへ移行する際、我々は以下の鉄則をチームに課すべきである。
1. `array` 型ヒントの全廃:
コードベース全体の型ヒントから `array` をパージせよ。代わりに `arraykey`、`varray`（移行期用の緩いベクタ）、あるいは完全に型安全な `vec`/`dict`/`keyset` を強制する。
2. `Shapes` との結合:
構造化されたデータ（DTO的用途）には、PHPの連想配列ではなく `shape` または Hackの `class` を使用し、キーのタイポをコンパイル時に検知する。
3. 安全なキャスト関数の活用:
外部APIやレガシーレイヤーからどうしてもPHPの `array` が流入する場合は、境界（Boundary）で `Dict\from_array()` や `Vec\from_array()` を用い、明示的に型安全な世界へサンドイッチする。
// 境界での安全な取り込み例
function parse_external_payload(mixed $raw_data): dict
// 境界で厳格な型アサーションを行う
invariant(\is_array($raw_data), ‘Payload must be an array’);
return \Dict\from_array($raw_data);
}
—
5. 結び：コードの信頼性はメモリレイアウトから始まる
優れたアーキテクトは、言語の表面的な美しさではなく、それがコンパイラをどう通り、CPUのキャッシュラインをどう揺らし、メモリ上でどう配置されるかにこだわる。
PHPの `array` は、初期のWebの歴史が生んだ偉大な妥協の産物である。しかし、現代の高スループット・高セキュリティが要求されるシステムにおいて、その「何でもあり」は最大の脆弱性であり、ボトルネックだ。
`vec`, `dict`, `keyset` への移行は、単なるコードのリファクタリングではない。それは、「ランタイムの予測可能性を取り戻し、マシンの物理的限界を限界まで引き出す」という、エンジニアの意志の表明なのだ。
コンパイラを信じよ。型チェッカーにすべてを委ねよ。そして、遅くて脆い動的配列の呪縛から、自らのコードベースを解放せよ。