PHPの亡霊を葬る：Hackのコレクション型への昇華とHHVMの深淵
PHPの `array` は、かつてウェブの銀の弾丸だった。しかし、それは「何でも入り」の闇鍋であり、現代の堅牢なシステムにおいては、型安全性を食い潰す最大の脆弱性ベクトルである。
本稿では、PHPの連想配列をHackの `vec`, `dict`, `keyset` へと変換する際、HHVMのランタイムが裏側で何を行っているのか、そしてなぜそれがパフォーマンスと堅牢性に直結するのかを、コアコミッターの視点から解剖する。
—
1. `array` の罪と、HHVMにおけるメモリの真実
PHPの配列は、実態としてハッシュテーブル（`zend_array` 相当）であり、挿入順序を保持する。だが、これは極めてメモリ効率が悪い。すべてのキーがハッシュ計算を要求し、メモリはポインタの海となる。
対してHackの `vec
- `vec
` : 連続したメモリ領域へのインデックスアクセスに最適化される。HHVMはこれをC++の `std::vector` に近いレイアウトで展開し、ポインタの参照解決を最小化する。 - `dict
2. 段階的移行の極意：`darray` / `varray` の罠を避ける
いきなり全ての `array` を `dict` に書き換えるのは、型チェッカーが叫び声を上げるだけの無謀な賭けだ。まずは、PHPの配列を「Hackの期待する型」へと強制する戦略を取る。
移行のステップ：
1. Shapeの導入: 構造が決まっている連想配列は、決して `dict
2. `keyset` の活用: 一意な値の集合ならば、`dict` ではなく `keyset` を使うこと。ハッシュ計算の効率が劇的に変わる。
// 悪い例: 意味のない型定義
function get_user(): dict
// 良い例: 形状を明示し、HHVMにメモリレイアウトのヒントを与える
type User = shape(
‘id’ => int,
‘username’ => string,
‘is_active’ => bool,
);
function get_user(): User {
// HHVMはこのShapeを解析し、オフセット計算を定数化する
return shape(‘id’ => 1, ‘username’ => ‘admin’, ‘is_active’ => true);
}
3. HHVMアーキテクチャから見た型推論の効能
なぜ型を厳格にすると速くなるのか？ 答えは 「型検査の静的化とガードの排除」 にある。
PHPの連想配列を扱う際、HHVMは常に「この値は本当に文字列か？」「このキーは存在するか？」というガードコードをJIT後のマシンコードに挿入せざるを得ない。しかし、Hackで型を明示すれば、HHVMの型チェッカー（`hh_client`）がコンパイル時にその正当性を保証する。
結果として、ランタイムはこれらのガードを省略し、「型チェックなしのダイレクトアクセス」を行うマシンコードを生成する。これが、HackがPHPを圧倒する真の理由だ。
4. パフォーマンスの限界を突破する：コレクションのイミュータビリティ
Hackのコレクション（`ImmVector`, `ImmMap` 等）は、イミュータブル（不変）であることを保証できる。これにより、HHVMは以下のような最適化を行う。
- 共有メモリの最適化: 複数のスレッドやコンテキスト間で、イミュータブルなコレクションをコピーせずに参照として渡すことが可能になる（RC: Reference Countingのコスト削減）。
- 構造共有: コレクションの一部を更新する際、全てを複製するのではなく、変更点のみを差分として扱う最適化がVMレベルで機能する。
結びに：エンジニアへの提言
PHPからHackへの移行は、単なる構文の書き換えではない。それは、「型という名の防御壁」をコードの基盤に再構築する作業だ。
型定義を疎かにすることは、VMに「推論のための計算コスト」を押し付けることに他ならない。シニアエンジニアである貴殿らが書くべきは、マシンが最も効率的に実行できる「静的な解」である。
`dict` を使い、`shape` を定義し、`mixed` を排除せよ。それが、システムを最も冷徹に、そして高速に駆動させる唯一の道である。
—
Hack Compiler Core Engineering Team / Chief Architect