はじめに：コードレビューで「なんとなく型をつける」を卒業せよ
テックリードの私が生コードレビューで最も絶望するのは、「とりあえずHHVMに怒られないようにするために `mixed` や `?array` を並べ、`Shapes::idx` で安全網を張り巡らせたような、静的解析の恩恵を自らドブに捨てるコード」だ。
Hack言語の真価は、単なる「PHPの親戚の静的型付け言語」ではない。厳格な静的型システム（Strict Mode）と、HHVM（HipHop Virtual Machine）のJITコンパイラが密に結合した「型駆動型実行時最適化（Type-Driven JIT Optimization）」の凄みにある。
今回は、Hackの型ヒントがいかにしてHHVMのJITコンパイラを調教し、生半可なJIT言語の追随を許さない圧倒的なスループットを生み出すのか。その内部メカニズムと、本番環境で生きる堅牢な設計パターンを解き明かそう。
—
1. 内部構造の真実：型チェッカーのメタデータはJITの「武器」である
PHPのJIT（PHP 8のOplog/JITなど）は、実行時のプロファイリング（Inline Caching等）に頼らざるを得ない。変数の型が動的に変わり得るからだ。
しかし、Hackの Strict Mode (`<
Hackの型チェッカー（hh_client / hh_server）は、コンパイル時に全ての式、プロパティ、メソッド戻り値の型を完全に確定させ、Bytecodeに厳格な型アサーションと型メタデータを焼き付ける。
JITコンパイラ（Region JIT / LLVMベースのバックエンド）が受ける恩恵
1. ボックス化（Boxing）の回避とアンボックシング（Unboxing）
PHPや緩い型の動的言語では、整数や浮動小数点数も「ヒープ上のオブジェクト（zvalなど）」として表現されがちだ。しかし、HHVMは厳格な型情報（`int`, `float`, `bool`）をもとに、これらをC/C++レベルのネイティブなレジスタ/スタック上のプリミティブ型として直接扱える。ポインタのデリレフェンスコストが消滅する瞬間だ。
2. メソッドディスパッチの単態化（Monomorphization / Devirtualization）
インターフェースや抽象クラスであっても、Strict Mode下で型が厳密に絞り込まれていれば、HHVMのJITは仮想メソッドテーブル（vtable）のルックアップをインライン展開（Inlining）し、静的な関数呼び出しへと昇華させる。
3. 冗長な型チェック（Type Guards）の排除
動的言語のJITは常に「この変数が本当にintか？」というガード命令を挟む必要がある。だが、HackのStrict Modeコードでは、コンパイル時に型が保証されているため、JITはガード命令を一切生成せず、純粋な機械語（Machine Code）を出力できる。
—
2. アンチパターン：なぜそのコードはJITを殺すのか？
次の2つのコードを見比べてほしい。どちらも同じ結果を返す。
【アンチパターン】型を曖昧にした「動的風」Hackコード
<
namespace App\Optimization;
class BadCalculator {
// mixed や array の多用は、JITの最適化パスを完全に破壊する
public function calculate(mixed $data): mixed {
$items = \is_array($data) ? $data : [];
$total = 0;
foreach ($items as $item) {
// $item の型が確定しないため、動的な加算処理（ZendVM的なオーバーヘッド）が発生
$total += Shapes::idx($item, ‘value’, 0);
}
return $total;
}
}
何が問題か？ `mixed` や `Shapes::idx` の多用により、HHVMは変数の型を追跡できなくなる。JITは「何が来るか分からない」ため、汎用的な遅いパス（generic slow path）を選択せざるを得ず、CPUパイプラインはストールする。
—
3. プロダクションコード例：JITを極限まで引き出す厳格なドメインモデル
では、どう設計すべきか？
型チェッカーに完全に型を教え込み、JITに最速の機械語を出力させるための、実務でそのまま使える堅牢なコンポーネント設計を示す。
<
namespace App\Optimization;
/
- 読み取り専用の厳格なデータ構造（ShapeではなくReadonlyまたはRecord/Classを活用）
- プリミティブ型のみで構成することで、メモリアロケーションを最小化する。
/
<<__Const>>
class OrderItem {
public function __construct(
public string $sku,
public int $quantity,
public float $unitPrice,
) {}
}
/
- 金融計算・高スループット処理を行うドメインサービス
/
final class OrderProcessor {
/
- すべての引数と戻り値が完全に具象型（Concrete Type）で定義されている。
- これにより、HHVMのJITはループと演算を完全にネイティブなマシン語にコンパイルする。
/
public function calculateSubtotal(vec
$subtotal = 0.0;
// vec
// HHVM内部で連続したメモリ領域に最適化され、キャッシュヒット率が極めて高い。
foreach ($items as $item) {
// プリミティブ型同士の乗算・加算は、CPUのFPU/ALU命令に直結する
$subtotal += ($item->quantity $item->unitPrice);
}
return $subtotal;
}
}
このコードが美しい理由と技術的根拠
1. `vec
2. 具象型プロパティとプリミティブ: `$quantity` が `int`、`$unitPrice` が `float` と完全に静的定義されているため、JITはボクシング（Boxed value）を行わず、CPUレジスタ上で直接計算を実行する。
3. `<<__Const>>` アトリビューート: イミュータビリティをコンパイラに保証することで、HHVMはフィールドの読み取りキャッシュやさらなるインライン展開の最適化を行える。
—
4. 非同期API連携とジェネリクス（Generics）のパフォーマンス特性
マイクロサービス間の通信や非同期API連携（`Awaitable`）においても、型の厳格さはJITとメモリ効率に直結する。
<
namespace App\Api;
use namespace HH\Asio;
interface IApiClient
public function fetchRawDataAsync(string $endpoint): Awaitable
public function deserialize(string $json): T;
}
final class StrictApiClient implements IApiClient
public function __construct(private string $baseUrl) {}
public async function fetchRawDataAsync(string $endpoint): Awaitable
// 非同期IO処理（HHVMのAsyncエグゼキューターにより効率的にスケジューリングされる）
// 実装は省略
return “[]”;
}
public function deserialize(string $json): vec
// 型安全なデシリアライゼーション
// 型チェッカーとJITの連携により、不正なデータの混入を早期に断つ
return vec[];
}
}
アーキテクトからの助言：非同期コンテキストでの型の重み
`Awaitable
—
まとめ：パフォーマンスは「型」から生まれる
多くの開発者は、「パフォーマンスを上げるためにC++拡張を書こう」あるいは「キャッシュサーバーを増やそう」と考えがちだ。しかし、それは対症療法に過ぎない。
Hack言語のStrict Modeを極め、HHVMのJITコンパイラが「何を推論でき、何を最適化できるか」を脳内トレースしながらコードを書くこと。それこそが、追加のインフラコストを払うことなく、ミリ秒単位の応答速度と鉄壁の堅牢性を両立させる唯一無二のエンジニアリングである。
コードレビューの際、`mixed` や緩い配列を見かけたらこう問うてほしい。
「その型、JITコンパイラを殺していませんか？」と。