HHVMの深淵を覗く：型システムがメモリとGCを支配するアーキテクチャの真実
Hackは単なる「PHPの型付きラッパー」ではない。HHVMという仮想マシンの上で、JITコンパイルと高度な型推論を武器に、動的言語の柔軟性と静的言語のパフォーマンスを融合させた希有な存在だ。
大規模なプロダクション環境でHackを運用する際、多くのエンジニアが「型は安全のため」としか考えていない。だが、真のアーキテクトは知っている。「型は、HHVMのメモリ管理戦略そのもの」であることを。
今日は、型システムがどうGCの負荷を減らし、大規模アプリケーションのレイテンシを削り出すのか、その極意を伝授しよう。
—
1. 悲劇の「再配置」：なぜ構造体の選択が重要なのか
PHP的な`array`（連想配列）は、HHVMにおいて非常に「重い」構造だ。これはハッシュテーブルであり、ポインタの塊である。一方、Hackの`shape`や`vec`、`dict`は、型情報が静的に確定している場合、VMレベルでメモリレイアウトを最適化できる余地が生まれる。
非効率なパターン：動的すぎる構造
// 悪い例: 毎回異なるキーを持つarrayを生成する
// これにより、HHVMはハッシュテーブルの再構築を繰り返す
function get_data(): dict
return dict[‘id’ => 1, ‘meta’ => vec[1, 2, 3]];
}
このコードは、型が`mixed`に逃げているため、HHVMは各要素を`TypedValue`としてボックス化せざるを得ない。メモリ上に散らばるオブジェクトへのポインタは、GC（Mark-and-Sweep）にとって最悪の敵だ。
推奨パターン：Shapeによる構造の静的固定
// 良い例: Shapeを用いて構造を固定する
// これにより、HHVMはメモリレイアウトを予測可能にする
type TUser = shape(
‘id’ => int,
‘score’ => int,
);
function process_user(TUser $user): int {
return $user[‘id’] + $user[‘score’];
}
`shape`を使用すると、HHVMはコンパイル時にオフセットを固定できる。これはメモリ上の連続領域を確保しやすくし、キャッシュミスを減らすだけでなく、GCのトラバース対象を最小限に抑えることを意味する。
—
2. HSLとメモリ効率：`vec`と`dict`を使いこなせ
PHP 7以降の配列は劇的に改善されたが、HHVMの`vec`と`dict`は、その上を行く。特にHSL（Hack Standard Library）のイテレータと組み合わせる際、不要なコピーを避けることがパフォーマンスの分水嶺となる。
実務で使える堅牢なパターン：イミュータブルな設計
大規模システムでは、状態の変更はバグの温床だ。しかし、コピーコストを恐れるあまり可変な設計にするのも危険。ここでの解は「イミュータブルなデータ構造の使い回し」だ。
use namespace HH\Lib\Vec;
// 巨大なリストを扱う際、Vec\map等は最適化されている
// 破壊的な操作を避け、新しい構造を生成する方が、HHVMのGCには優しい
function transform_scores(vec
return Vec\map($scores, $s ==> $s 2);
}
HHVMのGCは、世代別GC（Generational GC）を採用している。短命なオブジェクト（イミュータブルな変換の結果など）は第0世代（Nursery）で効率的に回収される。「一度作成したら書き換えない」設計は、GCの負荷を劇的に下げる。
—
3. 非同期処理とメモリリークの罠
`async` / `await` を多用する大規模API連携において、最も注意すべきは「クロージャによる循環参照」と「意図しないメモリの保持」だ。
悪い例：キャプチャによるメモリの肥大化
// 大規模なオブジェクトをasyncクロージャが保持し続けると、
// awaitの間、GCはそれを回収できない
async function fetch_data(LargeObject $obj): Awaitable
await do_something();
// $obj はここで不要だが、スコープを抜けるまで保持される
}
改善案：必要なデータのみを抽出する
async function fetch_data(int $id, string $data): Awaitable
// 必要最小限のプリミティブのみをクロージャに持ち込む
// これにより、親スコープの巨大オブジェクトが早期に解放される
await do_something();
}
—
まとめ：アーキテクトとしての心得
1. `mixed`を排除せよ: 型が不明瞭な場所には、HHVMの最適化は届かない。すべてのインターフェースは厳格な型で定義せよ。
2. `shape`と`record`を活用せよ: データの構造をVMに「教える」ことで、メモリレイアウトを最適化させる。
3. イミュータビリティを信じよ: 破壊的操作はGCを複雑にする。新しい構造を返す関数型のアプローチこそ、HHVMの性能を最大限に引き出す。
Hackという言語は、あなたが書いたコードの「意図」を最も深く理解しようとする言語だ。あなたが型という規律を持って設計すれば、HHVMは最高のパフォーマンスという報酬を返すだろう。
さあ、コードを開け。まだ型を緩くしている箇所はないか？ その小さな妥協が、数億リクエストの先で深刻なボトルネックに変わるのだ。