Hack Strict Modeへの回帰：型安全性の深淵とアーキテクチャの生存戦略
Hackのコードベースにおいて、`<<__Strict>>`は単なるアノテーションではない。それはHHVMのJITコンパイラに対する「型推論の放棄と契約の遵守」という宣戦布告だ。
大規模なレガシーコードベースを抱えるエンジニアにとって、Partial ModeからStrict Modeへの移行は、単なるリファクタリングではない。それは、メモリレイアウトの最適化と、実行時チェック（Type Assertion）という名の「動的なオーバーヘッド」をいかに殺すかという、究極の最適化プロセスである。
本稿では、型安全性を担保しながら負債を圧縮し、HHVMのパフォーマンスを極限まで引き出すための「境界線上の戦い方」を説く。
—
1. 境界線の設計：型安全性とPartial Modeの共存
大規模コードベースで最も恐ろしいのは、`mixed`型がウイルスのように伝播し、型推論の連鎖を断ち切ることだ。Strict Modeへの移行を成功させる鍵は、「型境界（Type Boundary）」の明確な隔離にある。
トレイトとインターフェースによる防御的隔離
Partial ModeのコードからStrict Modeのコードを呼び出す際、直接的な依存は避けるべきだ。HHVMの型チェッカーは、境界を越える際、動的な型チェックを生成する。これが積み重なると、CPUの分岐予測を狂わせ、インライン化を阻害する。
// Partial ModeからStrict Modeへの境界を強制するラッパー
// 外部からの入力を型検証し、Strict環境へ渡す「ゲートウェイ」として設計する
final class Gateway {
public static function invoke(mixed $input): string {
// 境界で厳格な型検証を行い、HHVMに確実な型情報を与える
if (!$input is string) {
throw new InvalidArgumentException(“Type mismatch at boundary”);
}
return StrictProcessor::process($input);
}
}
この「ゲートウェイ」パターンは、型チェッカーに対して明確な「型の再開（Type Resumption）」のポイントを提供し、コンパイラが最適化パスを適用しやすくする。
—
2. HHVMのメモリレイアウトと型の恩恵
Strict Modeで記述されたコードは、HHVMの`Repo-Authoritative`モードにおいて、型情報が静的に確定しているため、メモリレイアウトの最適化が極めて強力に機能する。
構造体（Shape）とBox化の回避
Hackの`shape`型は、適切に設計すればC言語の`struct`と同等のメモリ効率を実現できる。しかし、Partial Modeでは、フィールドの欠損や動的な追加により、HHVMは`Array`（内部的にはハッシュマップ）としてメモリを割り当てる。これはポインタを追いかけるコストを増大させる。
// 悪例：フィールドが動的に変化しうる形状
type TData = shape(‘id’ => int, …);
// 理想：Strict Modeで定義された固定形状
// HHVMはこれを固定オフセットのメモリとして配置できる
<<__Strict>>
type TStrictData = shape(
‘id’ => int,
‘timestamp’ => int,
);
型を固定することで、JITは「`id`フィールドは先頭から0バイト目にある」という物理的なオフセットをコンパイル時に確定できる。これはパフォーマンスにおいて決定的な差となる。
—
3. 型推論を殺す：`mixed`という名の技術的負債
Strict Modeへの移行で最大の難敵は`mixed`である。`mixed`が存在する限り、型チェッカーは「何も仮定できない」状態に陥る。
型の縮小（Type Narrowing）の極致
`mixed`を排除するために、安易なキャストを行ってはならない。それはランタイムチェックを増やし、パフォーマンスを殺す。代わりに、`is`演算子や`as`演算子を用いた型ガード（Type Guard）のパターンを徹底せよ。
<<__Strict>>
function processInput(mixed $data): void {
// 型ガードにより、スコープ内での型を確定させる
// HHVMの型チェッカーはこのifブロックを最適化し、分岐を削る
if ($data is vec
// このブロック内では $data は確実に vec
$this->compute($data);
} else {
// 負債の局所化：ログを吐き、あるいは安全にフォールバックする
invariant_violation(‘Type narrowing failed’);
}
}
—
4. 伝説のアーキテクトからの提言：負債管理の哲学
Strict Modeへの移行は、コードの「清潔さ」を求める作業ではない。HHVMの実行モデルに対して、コードの「意図」を正確に伝える作業である。
1. `<<__ExplicitStub>>` の活用: 移行初期段階では、Stubファイルを用いて型情報を先行定義し、徐々に実装をStrict化せよ。
2. `hhvm.check_type_assertions`の監視: 境界で発生しているランタイムチェックのコストをプロファイラで特定せよ。多すぎるチェックは、アーキテクチャ設計が甘いことの証明である。
3. 警告はエラーとして扱う: `hh.typechecker.options`で全ての型エラーを致命的なものとしてCIで弾け。妥協した瞬間に、そのコードは再びレガシーの墓場と化す。
Hack言語は、静的解析と動的実行の融合点にある。君たちが書く一行の型定義が、HHVMのJITパイプラインを最適化し、ミリ秒単位の応答速度を改善する。型安全性を信じろ。それこそが、大規模システムにおいて唯一スケールする「技術的負債への唯一の解」である。
—
Hackは、混沌の中に秩序を刻む作業である。コードの静的型を信じるな。コンパイラの推論を信じろ。そして、君自身の設計の厳格さを、何よりも信じよ。