【テクニカル・上級編】HackのShape型がJITで構造体アクセスに変換される仕組み：連想配列の高速化を支える内部実装 – Hack言語コア・静的型システムとHHVMのアーキテクチャ解析バイブル

Hack言語を単なる「PHPの強化版」と捉えているのであれば、君の認識は浅い。HHVMの心臓部において、`shape`型が単なる連想配列のエイリアスではないことは、型チェッカーを通過した瞬間に確定する物理的な事実だ。

今日は、動的言語の悪夢である「ハッシュテーブル探索」という名の非効率を、いかにしてJITコンパイラが「オフセットアクセス」という極限の最適化へ昇華させているのか。その内部機構を解剖する。

—

PHPの連想配列（`array`）は、内部的には`darray`として実装されており、ハッシュテーブルに基づいている。キーが文字列であれば、検索のたびにハッシュ値を計算し、衝突回避のためにリンクを辿り、メモリ上の遠い箇所へポインタを飛ばす。

// 典型的な連想配列（非効率の温床）
$data = [‘id’ => 1, ‘score’ => 100];
// 実行時：ハッシュ計算 -> バケット検索 -> 値のロード

この「動的な柔軟性」は、高速なCPUキャッシュラインを破壊する最大の要因だ。JITコンパイラにとって、フィールドの配置が実行時にしか確定しないデータ構造は、最適化の死神である。

Hackの`shape`は、開発者が型チェッカーに提示する「契約」である。しかし、この契約は単なる静的解析のためのメタデータではない。JITコンパイラはこの情報を利用して、メモリレイアウトを静的に計算可能な「構造体（Struct）」へと強制変換する。

`shape`が定義された瞬間、HHVMの型システムは以下のように変換を行う。

1. フィールドの固定化: キー（文字列）をコンパイル時にオフセット（整数）にマッピングする。
2. スロットの割り当て: 構造体のメモリ領域を単一の連続したブロックとして確保する。

ここからが本題だ。HHVMのJITコンパイラ（`HHBC`）は、コードが`shape`であることを検知すると、ハッシュ関数を通すコードを生成しない。代わりに、固定されたオフセットへのポインタ演算を直接命令に落とし込む。

// コンパイル前：$s[‘score’]
// コンパイル後（JITが生成する機械語に近い表現）：
// 1. レジスタ rax に $s のベースアドレスをロード
// 2. [rax + 8] （scoreフィールドのオフセット）を直接参照

この変換により、CPUはハッシュの衝突やバケットの走査をすることなく、メモリ上の特定の座標を直接叩く。これは、C言語の`struct`を扱うのと同等のパフォーマンスである。

さらに賢いことに、HHVMは単なる構造体化に留まらない。もしshapeの構造が単純であれば、内部データ表現を`PackedArray`（インデックスが整数の配列）に準ずる形式に最適化する。

これにより、メモリ使用量は劇的に削減される。大規模なデータセットを扱う際、ヒープの断片化（Fragmentation）を抑え、GCの負荷を最小化する鍵がここにある。

このアーキテクチャを理解すれば、コードの書き方が変わるはずだ。

`shape`を多用せよ: `dict`や`array`を使う理由は、もはや「実行時にキーが不明」な場合しかない。型が判明しているなら、迷わず`shape`を使え。それがコンパイラに「ここを最適化してくれ」と命じる唯一の手段だ。
`shape`のサイズに注意: 巨大な`shape`は、かえってメモリの局所性を乱す。論理的に単位となる構造ごとに分割し、ネストさせることで、キャッシュ効率を最大化する。
型推論の限界を理解する: `shape`が`mixed`にキャストされる瞬間、すべての静的最適化は崩壊し、低速なハッシュテーブル検索にフォールバックする。型を逃がすな。

—

HHVMにおける`shape`とは、動的言語の自由と、静的言語の速度という、本来相容れないはずの二つの世界を繋ぐ「架け橋」だ。

メモリのオフセットを支配する者が、パフォーマンスを支配する。もし君がこの最適化の恩恵を最大限に引き出したいのであれば、単にコードを書くのではなく、HHVMが生成する中間表現（HHBC）を覗き、コンパイラがどのように君の意図を機械語に変換しているかを常に意識することだ。

真のシステムアーキテクトに魔法は不要。必要なのは、ハードウェアの挙動とコンパイラの仕様に対する、冷徹なまでの洞察だけである。