【テクニカル・上級編】Hackの`darray`と`varray`から`dict`と`vec`への移行：型システムの進化を追う – Hack言語コア・静的型システムとHHVMのアーキテクチャ解析バイブル

境界なき型安全性への回帰：`darray`/`varray`の廃止と`dict`/`vec`がもたらしたHHVMの最適化

Hack言語の進化を追うことは、動的型付け言語の混沌から、いかにして「予測可能なメモリレイアウト」と「堅牢な型安全」を両立させるかという、計算機科学における長年の挑戦を追うことに等しい。

かつて、PHPの「配列」という名の万能コンテナは、その柔軟性と引き換えに、JITコンパイラにとっての最大の悪夢であった。`darray`と`varray`の導入は、型システムを厳格化するための過渡期的な「足枷」だった。そして現在、我々は`dict`と`vec`という、ランタイムと型チェッカーが完全に調和する到達点にいる。

本稿では、単なる構文の変更という表面的な議論を排し、この移行がHHVMのアーキテクチャにどのような「構造的規律」をもたらしたかを深掘りする。

—

1. なぜ「配列」は悪夢だったのか：メモリの不確実性

かつてのPHP配列は、ハッシュマップであり、リストであり、スタックでもあった。HHVMのJITエンジンにとって、型が確定しない配列へのアクセスは、毎回「型ガード（Type Guard）」の生成と、メモリ上のオフセット計算という重いコストを強いる。

`darray`と`varray`は、この曖昧な配列を「マップ」と「リスト」に分離しようとした試みだった。しかし、これらは内部実装上、依然として「PHP配列」のレガシーを色濃く引きずっており、ランタイムの最適化を阻害する「中間層」に過ぎなかった。

構造的な決別：`dict`, `vec`, `keyset`

これらは、HHVMのランタイム内部において、「単一のメモリレイアウト」を持つことを保証されている。

`vec`: 連続するメモリ領域。インデックスアクセスは$O(1)$であり、JITは配列の境界チェックを静的に排除できる。
`dict`: 衝突を最小限に抑えた高速なハッシュテーブル。キーの型が固定されるため、ハッシュ関数の計算も最適化される。

—

2. 型チェッカーが強制する「境界の防衛」

HackのStrictモードにおいて、`darray`から`dict`への移行を強いることは、単なるリファクタリングではない。これは、「プログラムの入力地点（API境界）での不変条件の確定」を意味する。

以下のコードを見てほしい。

<<__EntryPoint>>
function main(): void {
// 従来のdarray的な書き方は、HHVMの型チェッカーによって警告が出る
// dictは型システムと完全に統合されており、キーと値の型が推論可能
$data: dict = dict[
‘user_id’ => 1024,
‘access_level’ => 3,
];

// vecへの移行により、配列外アクセスはコンパイル時に検知可能
$list: vec = vec[‘admin’, ‘editor’, ‘viewer’];

// vecのイテレーションは、HHVMのプロファイラが「ホモジニアスな型」として認識するため
// LLVMの最適化パスが効きやすい
foreach ($list as $role) {
echo $role . “\n”;
}
}

このコードにおいて、`dict`と`vec`を使用することは、コンパイラに対して「このメモリ構造は実行中に変化しない（Shapeの不変性）」という強力なヒントを与えている。これにより、JITはガード命令を大幅に削減し、CPUのパイプラインを止めることなく分岐予測を成功させることが可能になる。

—

3. シニアエンジニアが知るべき「メモリ配置と最適化」

`darray`が廃止された真の理由は、メモリの断片化とポインタ・チェイシング（Pointer Chasing）の回避にある。

HHVMにおいて、`vec`は単一の連続的なメモリブロックとして確保される。これが意味するのは、CPUのL1/L2キャッシュに対する極めて高い親和性だ。一方で、旧来の配列はエントリごとにメモリが散らばる可能性があり、キャッシュミスが頻発する設計だった。

セキュリティの観点から

型システムが厳格であることは、セキュリティの最前線においても武器になる。`dict`と`vec`への強制移行は、ランタイムでの型混乱攻撃（Type Confusion）の余地を限りなくゼロにする。

無効なキーアクセス: `dict`はキーの存在チェックを型システムレベルで要求する。
型情報の保持: HHVMのメモリレイアウトにおいて、`dict`と`vec`はメタデータに型情報（Type Tag）を効率的に保持しており、リフレクションやデバッグ時にも型安全性が担保される。

—

結論：進化を止めるな

`darray`と`varray`という過渡的な存在が消え去ったことは、HHVMが「真に予測可能な実行環境」へ進化したことを示している。我々が書くコードは、単なる命令列ではなく、コンパイラが読み取り、最適化し、安全性を保証するための「構造化された数学的記述」であるべきだ。

移行をためらうことは、自らのコードのパフォーマンスと安全性を、過去の遺物の中に閉じ込めることに等しい。今すぐプロジェクトをStrictモードで再評価し、`dict`と`vec`への完全移行を完了させよ。それが、大規模アーキテクチャを支えるチーフアーキテクトとしての、唯一の正解だ。

—
「コードは書かれるものではない。コンパイルされるために、精緻に設計されるものだ。」