【実務・中級編】Hackのコレクション型（Vector, Map）とJITの最適化効率 – Hack言語コア・静的型システムとHHVMのアーキテクチャ解析バイブル

Hackのコレクション型とHHVM JITの深層：なぜ`Vector`や`Map`はネイティブ配列を超えるのか

コードレビューをしていて、次のようなコードに出くわしたことはないだろうか。

// 典型的なアンチパターン
$data = Map {};
foreach ($items as $item) {
$data[$item->id] = $item->name;
}

「動的にキーと値をバインドできているし、型もついているから問題ない」と思ったとしたら、HHVM（HipHop Virtual Machine）のJITコンパイル構造とHackの型システムの裏側を過小評価している。

我々はWebエンジニアとして、単に「動くコード」を書く時代を過ぎた。数千万リクエストを捌くプロダクション環境において、メモリレイアウトとJITの最適化パスを意識したデータ構造の選択は、CPUキャッシュヒット率を左右し、最終的なインフラコストを何倍も変動させるクリティカルなファクターだ。

今回は、Hackの標準コレクション型（`Vector`, `Map`, `Set`）がHHVMのJITエンジン内部でどのように特別扱いされ、いかにして爆速なアクセスを実現しているのか。その内部実装と、実務で絶対に押さべき設計パターンを叩き込む。

—

1. PHPの配列の幻想と、Hackコレクションの物理的実態

PHPの原罪は、アソシエィティブ・配列（`array`）という名の「万能だが遅いハッシュマップ」にある。PHPの配列は、ハッシュテーブルと双方向リストが入り混じった複雑な構造をしており、メモリ上に散らばりやすい。

一方、Hackの `Vector` や `Map` は違う。

Vectorの内部構造：連続したメモリ領域

`Vector`の本質は、C++の `std::vector` に近い。要素はヒープ上の連続したメモリ領域（Contiguous Memory）に配置される。
これにより、何が起きるか？

1. CPUキャッシュの局所性（Cache Locality）:
イテレーション時にCPUのプリフェッチ機構が劇的に効く。キャッシュミスが激減する。
2. ポインタ追跡の排除:
メモリが連続しているため、インデックスアクセス（`$vector[$i]`）は、ベースアドレスからのオフセット計算（$Base + i \times Size$）という単一のCPU命令にコンパイルされる。

Mapの内部構造：オープンアドレス法とJITのインライン化

`Map`はハッシュ構造だが、HHVMのJIT（RepoAuthoritativeモード）は、型チェッカーによって保証されたキーと値の型情報を元に、ハッシュ計算とバケット探索のコードをネイティブマシン語にインライン展開（Inlining）する。

通常のPHPコードであれば動的なハッシュルックアップになるところを、JITは「このMapのキーは厳格に `int` であり、衝突確率は極めて低い」と判断し、最適化された高速パス（Fast Path）を生成するのだ。

—

2. JITを味方につける：プロダクションコード設計パターン

では、実際のシステム開発において、どのようにこれらを使い分けるべきか。
ここでは、ドメインモデルのデータを集約し、非同期API連携のペイロードを構築する堅牢なリポジトリ層のコードを例に示す。

以下のコードは、型安全性を極限まで高めつつ、HHVMのJIT最適化を最大限に引き出すプロダクションクオリティの設計パターンだ。

namespace App\Repository;

use namespace HH\Lib\{C, Vec, Dict};
use type App\Model\UserEntity;
use type App\Service\ExternalApiClient;

<<\Hermetic>>
final class UserAggregationRepository {

// イミュータブルなVectorを保持する
private Vector $users;

public function __construct(
private ExternalApiClient $apiClient,
) {
$this->users = Vector {};
}

外部APIからデータを一括取得し、最適化されたVectorとしてメモリ上に展開する。
@param vec $userIds
@return Awaitable

/
public async function hydrateUsersAsync(vec $userIds): Awaitable {
// 非同期境界を跨ぐネットワークI/O
$rawResponses = await Vec\map_async(
$userIds,
async $id ==> await $this->apiClient->fetchUserDataAsync($id)
);

// Vectorへのバルクインサート
// 連続メモリ領域への書き込みとなるため、動的な配列拡張よりもオーバーヘッドが少ない
$this->users->clear();
foreach ($rawResponses as $data) {
$this->users->add(
UserEntity::fromArray(shape(
‘id’ => $data[‘id’],
‘name’ => $data[‘name’],
‘email’ => $data[‘email’],
))
);
}
}

高速なO(1)インデックスアクセスを活用したフィルタリング
JITがループアンロールやベクトル化を行やすい構造にする

/
public function getActiveUsersAsMap(): Map {
$result = Map {};

// Vectorの連続メモリ走査はJITのネイティブコード生成において非常に有利
for ($i = 0; $i < C\count($this->users); $i++) {
$user = $this->users[$i];
if ($user->isStatusActive()) {
// Mapへの代入。型が静的に確定しているため、
// HHVMは動的な型チェックをバイパスして直接ハッシュスロットへ書き込む
$result[$user->getId()] = $user->getName();
}
}

return $result;
}
}

コードレビューの視点：なぜこの実装が優れているのか？

1. `<<\Hermetic>>` 属性の活用:
副作用を厳格に制限し、JITコンパイラに対して「このスコープ内のグローバル状態は変化しない」という強力なヒントを与えている。これにより、JITはレジスタ割当の最適化を agressively（攻撃的）に行える。
2. `for` ループと `C\count` の組み合わせ:
不必要なイテレータオブジェクトの生成を避け、プリミティブな整数インクリメントによる走査を行うことで、JIT上のループ最適化（Loop Unrollingなど）の恩恵を100%受けることができる。
3. `Vector` から `Map` への適切な役割分担:
「順序を保ったシーケンシャルな保持・走査」には `Vector` を使い、「一意なキーによるO(1)ルックアップ」には `Map` を使う。この適材適所のデータ構造選択が、メモリ断片化を防ぐ最大の防御壁となる。

—

3. 避けるべきアンチパターンとパフォーマンスの罠

チーフアーキテクトとして、現場で絶対に排除すべき「JITの最適化を殺す悪手」を警告しておく。

罠1: コレクションとHackのビルトイン `vec` / `dict` の混同

Hackには `Vector` や `Map` の他に、言語組込の型である `vec`, `dict`, `keyset` が存在する。
現代のHackにおいて、特別な理由（mutableなオブジェクトとして状態を保持し続ける必要がある等）がない限り、`Vector` や `Map` よりも `vec` や `dict` を使うべきだ。

なぜなら：

`vec` や `dict` は完全なイミュータブル（不変）として扱われ、HHVMの内部アロケータ（Jemalloc等との連携）において極めて効率的にメモリ管理される。
余計なメソッド呼び出しオーバーヘッドがなく、型チェッカーとJITの連携が最も洗練されている。

罠2: ループ内でのコレクションの動的拡張（再割り当て地獄）

// 最悪のパターン
$vec = Vector {};
foreach ($hugeDataSet as $row) {
// 要素数がキャパシティを超えると、内部でメモリの再確保とコピーが発生する
$vec[] = $row->process();
}

データサイズが事前に推測できる場合は、あらかじめキャパシティを確保するか、一度 `vec` で構築してから一括して `Vector::fromItems()` で変換するアプローチを取るべきだ。メモリの再割り当て（Reallocation）は、JITがいかに高速であっても隠しきれない重いペナルティとなる。

—

結び：型とメモリレイアウトを支配する者が、システムを制す

Hackの静的型システムとHHVMのJITコンパイラは、魔法の杖ではない。しかし、開発者が「そのコードがメモリ上でどう振る舞い、CPUのどのパイプラインを流れるか」を理解して書いたコードに対しては、C/C++に迫る驚異的なパフォーマンスで応えてくれる。

「動けばいい」という妥協を捨て、型、メモリ、そしてJITの挙動を脳内トレースせよ。
君たちの書く一行のコレクション操作が、サービスのレイテンシを削り、ビジネスのスケールを支えるのだ。