型ガードの深淵：HHVM JITにおける「見えないコスト」を制御する
Hackの型システムは、単なる開発時のエディタ補助ツールではない。それはHHVMという巨大な計算機が、実行時に「何が起きるか」を事前に確信するための「契約（Contract）」である。
多くのエンジニアは `TypeChecker` を通すことに満足するが、真にコードを掌握する者は、その先のHHVMが生成する 「型ガード（Type Guard）」 のコストに目を向ける。今回は、JITコンパイルの裏側で発生する命令サイクルを最小化し、実行性能の極限を引き出すための設計指針を共有しよう。
—
1. JITが挿入する「見えない番人」の正体
HHVMのJITエンジン（TransUnit）は、実行時に型が不確定な場合、必ず型ガードを挿入する。例えば、`mixed` 型や、推論が曖昧なインターフェースを介したアクセスだ。
// このコードは、一見クリーンに見えるが…
function process(mixed $data): void {
// ここでHHVMは実行時型チェック（Type Guard）を挿入する
// $dataがintかstringか、あるいはnullか？
// 実行時にマシン語レベルの条件分岐(Branch)が生成される
print (string)$data;
}
この「型ガード」は、CPUのパイプラインを乱し、投機的実行の精度を落とす。大規模なループ内であれば、この微細な分岐がキャッシュミス以上の致命的なレイテンシを生む。我々が目指すべきは、「JITが型チェックの命令を生成しなくて済む（Proof-carrying）コード」の記述だ。
—
2. 型ガードを殺すための「型洗練（Refinement）」戦略
HHVMのJITは、変数の型が「不変（Immutable）」であることを証明できれば、型ガードを完全に排除できる。これを効率的に行うには、制御フローの入り口で型を固定（Pinning）することだ。
悪いコード：ループ内での再評価
function bad_loop(vec
foreach ($items as $item) {
// 毎回ここで型チェックが走る可能性がある
if ($item is int) { / … / }
}
}
良いコード：型アサーションによるガードの静的昇格
function optimized_loop(vec
// 事前に型を絞り込み、JITのトレース内での型ガードを抑制する
$ints = vec
foreach ($items as $item) {
if ($item is int) $ints[] = $item;
}
// ここでの $ints は vec
// JITは型ガードを一切生成せず、純粋なメモリアクセス命令のみを生成する
foreach ($ints as $i) {
// No type guard here. Direct memory access.
}
}
—
3. HHVMアーキテクチャの核心：プロファイリングとガードの排除
HHVMのJITは、コードの実行頻度に基づいて「ホットトレース」を作成する。型ガードが存在する場合、そのガードを通過した先でしか最適化は機能しない。
型ガードを最小化する設計において重要なのは、「共用体型（Union Types）の回避」と「具象型の強制」である。
マシン語レベルでの最適化の差
1. 型ガードあり: `cmp` (compare) -> `jne` (jump if not equal) -> `handle_error`
2. 型ガードなし: `mov` (move) -> `add/mul` (math)
この `cmp` と `jne` が並ぶ回数を減らすことこそが、高トラフィックなサービスにおいてCPU使用率を10%削減する鍵となる。
—
4. 極限の設計：`shape` と `class` のメモリレイアウト
Hackの `shape` は、適切に使えば `stdClass` や連想配列よりも遥かに高速だ。なぜか？ それは、HHVMが `shape` のメモリレイアウトをオフセットとして固定できるからだ。
type TPoint = shape(‘x’ => int, ‘y’ => int);
function distance(TPoint $p1, TPoint $p2): int {
// $p1[‘x’] は、メモリ上の特定のオフセットへ直接アクセスする命令に置換される
// 連想配列のハッシュ検索は発生しない
return ($p1[‘x’] – $p2[‘x’]) 2 + ($p1[‘y’] – $p2[‘y’]) 2;
}
もし、ここで `$p1` が `mixed` であれば、HHVMはハッシュテーブルの探索ルーチンを呼び出さざるを得ない。型を `shape` に固定することで、ランタイムのハッシュテーブル検索（O(1)といえど重い）から、単純なレジスタへのロードへと格上げされるのだ。
—
最後に：チーフアーキテクトからの提言
Hackで最高のパフォーマンスを引き出すには、「コンパイラを信用しつつ、コンパイラの脳内を覗く」ことだ。
1. `mixed` を撲滅せよ。 逃げ道としての `mixed` は、型ガードという名の負債を積み上げる。
2. `is` 演算子を境界線として使え。 関数の入り口で型を確定させ、その関数内では「疑う余地のない型」として振る舞わせる。
3. HHVMのプロファイラを読め。 `hhvm.jit_profile_path` を活用し、どのトレースでガードが頻発しているかを確認する。
JITは魔法ではない。それは、君が書いた型定義という「論理」を、マシン語という「物理」に翻訳する機械だ。君が厳格であればあるほど、機械は饒舌に、そして高速に動作する。
さあ、コードを書き直せ。型ガードの排除こそが、至高のシステムへの唯一の道だ。