脱・泥沼：Hackの「Any」を殲滅し、Strict Modeの聖域へ到達する戦略
HHVMのコードベースを長年見守ってきた者として断言する。`mixed` 型の蔓延は、単なる「型チェックの怠慢」ではない。それは、VMの最適化パスを阻害し、ランタイムの予測可能性を奪う「アーキテクチャの癌」だ。
Hackの `hh_client` が `Any` 型や不完全な型定義に遭遇した瞬間、コンパイラはそこで推論を諦め、JITコンパイル時の最適化を放棄する。結果として、メソッドディスパッチのインライン化は阻害され、ガード条件は肥大化し、メモリレイアウトは不安定になる。
本稿では、レガシーなPartial Modeのコードを、型安全の要塞であるStrict Modeへと変貌させるための「冷徹な戦術」を伝授する。
—
1. なぜ「Any」がランタイムの敵なのか
HHVMは、静的型情報が完全である場合にのみ、その真価を発揮する。`Any` 型（あるいは不適切な `mixed` の使用）は、HHVMのバイトコードインタプリタに「ランタイム型検査を強制する」という重い負荷を課す。
- JITの最適化阻害: 型が不明瞭な場合、VMは命令実行時に必ず型ガードを挿入せねばならない。これが頻発すれば、CPUの分岐予測は破綻し、パイプラインはストールする。
- メモリ表現の非効率性: `int` や `string` が分かっていればスタック上に直接配置できる値も、`mixed` になればポインタ経由のボックス化（Boxed Value）を余儀なくされる。これはメモリ使用量の増大と、それに続くGCの圧力を引き起こす。
—
2. 段階的殲滅戦術：リファクタリングの鉄則
一気に全ファイルを `<<__Strict>>` にするのは自殺行為だ。以下の階層的なアプローチを取れ。
Step 1: 境界の封鎖（Interfaceによる型束縛）
既存の `mixed` があふれるクラスに、まずはインターフェースを導入する。これにより、疎結合を維持しつつ、依存先に対する型契約を強制できる。
// Bad: 型が特定できないレガシーなメソッド
public function process(mixed $data): mixed { … }
// Good: 契約による境界の定義
interface IDataProcessor {
public function process(shape(‘id’ => int, ‘payload’ => string) $data): bool;
}
Step 2: Shapeによる構造型への置換
`Any` が使用されている場所の多くは、単なる「データ構造」だ。連想配列を `shape` に置き換えるだけで、HHVMは該当データのオフセットをコンパイル時に確定できる。
// コンパイラに形状を教える
type TUserRecord = shape(
‘id’ => int,
‘username’ => string,
‘flags’ => int,
);
// 型チェッカーは、この時点でメモリオフセットの計算を最適化する準備に入る
function update_user(TUserRecord $user): void {
// $user[‘id’] へのアクセスは、ハッシュマップ検索ではなく、
// 固定オフセットのポインタ演算に置換される可能性がある
}
Step 3: `HH\FIXME` の追跡と排除
`hh_client` のエラーを黙らせるために `HH_FIXME` を乱用しているチームは、いずれシステム崩壊を招く。CIパイプラインにおいて、`HH_FIXME` の数をメトリクスとして監視せよ。
FIXMEの残存数を監視し、減らすことをKPIにする
hh_client –json | jq ‘.errors | map(select(.message[].code == 4110)) | length’
—
3. 型チェッカーを味方につける：ジェネリクスの活用
`Any` を回避する最大の武器はジェネリクス（Generics）だ。特に `reified` を活用することで、ランタイムにおいても型情報を保持できる。
// 再帰的な型制約とReifiedの活用
class Registry
private vec
public function add(T $item): void {
$this->items[] = $item;
}
public function getItems(): vec
return $this->items;
}
}
この実装により、ランタイムの境界で型チェックが行われ、`mixed` が侵入する隙間を物理的に排除できる。
—
4. 伝説のアーキテクトからの助言
Strict Modeへの移行は、単なる「警告の修正」ではない。「コードの意図をコンパイラに正確に翻訳する作業」だ。
1. Null許容型の撲滅: `?T` を多用するな。`Option` パターンを意識し、値が存在しない可能性を型システムで表現せよ。
2. 不変性（Immutability）の導入: `immvec` や `immmap` を活用し、サイドエフェクトを型レベルで封じ込めろ。
3. パフォーマンスへの直結: 型が厳格になればなるほど、HHVMのプロファイラは無駄なガードコードを削ぎ落とし、バイナリは研ぎ澄まされる。
型安全とは、単なる安全性向上のためのコストではない。究極のパフォーマンスを引き出すための、最も洗練されたコード規律である。
さあ、今すぐ `hh.php_version` を引き上げ、`<<__Strict>>` の宣言を全ファイルに書き込み、HHVMの真の力を解放せよ。それができるのは、我々エンジニアだけなのだから。