Strict Modeで『mixed』型を排除する：レガシーなPHPコードを段階的に型安全にするためのリファクタリング・ロードマップ
大規模なPHPコードベースをHackへと移行し、HHVM（HipHop Virtual Machine）の恩恵を最大化しようとする際、最大の障壁となるのは「動的型の負債」である。その象徴が `mixed` 型だ。
多くの開発者は、`mixed` を「任意の型を受け入れるための便利なプレースホルダー」程度に考えている。しかし、HHVMのランタイム内部とJITコンパイラの挙動を知る者にとって、`mixed` の放置はパフォーマンスと型安全性の双方に対する深刻な自傷行為に他ならない。
本稿では、HHVMコアコミッターの視点から、`mixed` がいかにして仮想マシンの実行効率を破壊するかを低レイヤレベルで解き明かす。その上で、レガシーなコードベースを安全かつ段階的に極限の型安全（Strict Mode）へと引き上げるための実践的リファクタリング・ロードマップを提示する。
—
1. `mixed` がHHVMランタイムを遅延させる内部メカニズム
なぜ `mixed` は悪なのか。それを理解するには、HHVMのメモリ管理とJITコンパイラが値をどう扱うかを理解する必要がある。
1.1 `TypedValue` の構造とレジスタアロケーション
HHVM内部において、すべての変数は `TypedValue`（通称 `TV`）という16バイトのC++構造体（またはそれに準ずるレジスタ表現）として表現される。
// HHVMソースコード（runtime/base/typed-value.h）の概念的抽象
struct TypedValue {
Value m_data; // 8バイト: ポインタ、int64_t、double等
DataType m_type; // 1バイト: KindOfInt64, KindOfString, KindOfVec等
// … 残りはアライメントおよびガベージコレクション用メタデータ
};
関数が `mixed` を返す、あるいは引数に `mixed` を受け取る場合、HHVMはコンパイル時にその変数の `DataType` を特定できない。この事実が、JITコンパイラ（VASM）による最適化をことごとく破壊する。
1. ガード（Guard）のインフレーション:
JITコンパイルされたマシンコード（Translation Cache / TC）は、特定の型を前提とした最適化を試みる。しかし、入力が `mixed` の場合、JITは値を使用する直前に毎回 `m_type` を検証するガード命令（`cmp` および条件分岐）を挿入せざるを得ない。
2. レジスタアロケーションの失敗:
型が確定（例: `int`）していれば、JITはCPUの汎用レジスタ（例: `RAX`）に直接値を保持し、生のCPU命令で演算を行える。しかし、`mixed` では常に `TypedValue` 構造体全体のメモリ表現、あるいはレジスタペア（値用と型タグ用）を維持せざるを得ず、レジスタ圧迫（Register Pressure）を引き起こしてメモリへの退避（Spilling）が発生する。
3. 参照カウント（RC）操作のオーバーヘッド:
型が不明な場合、HHVMは値の破棄や代入のたびに「この値は参照カウントを持つ型（`String`, `Array`, `Object` 等）か？」をランタイムで判定し、条件分岐を挟んで `decRef`/`incRef` を呼び出す必要がある。これは、メモリバスへの不要なアクセスを急増させる。
—
2. Strict Mode移行への3段階ロードマップ
レガシーなコードベースを一撃で `Strict Mode`（ファイルの先頭に `<
API境界での型制約 Type Refinementと Reified Genericsによる
(Shapes::idxの駆逐) 型アサーションの最適化 ランタイム型情報の完全同期
—
Phase 1: 境界の要塞化（API境界における `mixed` の排除）
レガシーコードの内部ロジックは後回しにし、まずはモジュール間を跨ぐ関数、クラスのパブリックメソッド、APIの境界から `mixed` を徹底的に排除する。
ターゲット：レガシーな動的配列と `Shapes::idx` の駆逐
レガシーPHPの最大の温床は、連想配列（旧 `array`）をマップとして使い回すパターンである。Hackではこれを `dict
既存のアンチパターン（リファクタリング前）
であるため、呼び出し側は常に mixed を受け取る
public static function getUserData(int $id): dict
// データベースからのフェッチを模した動的配列
return dict[
“id” => $id,
“username” => “shiva_architect”,
“is_admin” => true,
];
}
}
改善パターン（リファクタリング後）
API境界において、構造化されたデータには `shape` を適用し、かつ `Shape` の型定義を厳格にする。
int,
‘username’ => string,
‘is_admin’ => bool,
? ‘email’ => string, // オプショナル
);
class UserStrictService {
// 戻り値を明確に定義することで、JITは呼び出し側の型を推測可能になる
public static function getUserData(int $id): UserPayload {
return shape(
‘id’ => $id,
‘username’ => “shiva_architect”,
‘is_admin’ => true,
);
}
}
この変更により、`hh_client` は呼び出し側が `$data[‘username’]` にアクセスした際、それが確実に `string` であると静的に認識できる。HHVMは型ガードなしで直接文字列操作の最適化パスを選択可能になる。
—
Phase 2: 静的解析のハック（Type Refinement とアサーションの最適化）
境界を定義しても、内部にレガシーなサードパーティライブラリや動的JSONデコードが存在する場合、どうしても `mixed` がコードベース内に侵入する。これらを安全に「洗練（Refine）」させるテクニックが必要だ。
`as` アサーションのコストと、`TypeRefinement` の活用
Hackには強力な型洗練システムがある。`mixed` を安全な型にキャストする際、`as` 演算子を使用するが、これはランタイムチェックを伴う。
;
// さらに個別のキーを洗練させる
$id = $payload_dict[‘id’] as int;
// ここからは $id を完全な int としてレジスタに保持できる
doSomething($id);
}
HHVM JITの視点：
`as` は単なる静的キャストではない。HHVMはここに `Instanceof` または `DataType` の直接比較命令を生成する。
これをループの内部などで頻繁に行うと、JITはループ不変式（Loop Invariant）としての最適化ができず、オーバーヘッドが蓄積する。
最適化アプローチ：パターンマッチングによる分岐の集約
`as` で例外を発生させるのではなく、`is` 演算子と早期リターン（ガード節）を組み合わせることで、JITに「このブロック内では型が確定している」というコンテキストを教え込む。
) {
throw new InvalidArgumentException(“Invalid payload type”);
}
$id = $payload[‘id’] ?? null;
if (!$id is int) {
throw new InvalidArgumentException(“ID must be an integer”);
}
// これ以降、HHVMは $id を完全にネイティブな 64bit 整数（int64_t）としてレジスタにバインドする
doSomething($id);
}
—
Phase 3: 具現化されたジェネリクス（Reified Generics）への昇華
`mixed` が最も頻出するのが、汎用的なコンテナやデータ構造の設計時である。通常のジェネリクス `T` は、コンパイル時に「型消去（Type Erasure）」され、HHVMランタイム上では単なる `mixed`（`TypedValue`）として扱われる。
これを克服し、ランタイムでも型安全性を担保してJITの最適化を極限まで引き出すのが Reified Generics（具現化されたジェネリクス） である。
レガシーな型消去コンテナから、Reifiedコンテナへのリファクタリング
リファクタリング前（型消去: ランタイム上は `mixed`）
{
public function __construct(private T $data) {}
public function getData(): T {
return $this->data;
}
}
// 使用例
function handleBox(Box
// ランタイム上、Boxクラスは $data が int であることを知らない。
// そのため、getData() の結果を受け取る際、JITは型ガードを省略できない。
$val = $box->getData();
}
リファクタリング後（具現化ジェネリクス: ランタイムに型を伝搬）
`reify` キーワードを付与することで、HHVMはクラスインスタンス生成時に型メタデータ（`string` や `int` のクラス表現）をコンストラクタに隠蔽して渡す。
{
public function __construct(private T $data) {}
public function getData(): T {
return $this->data;
}
// ランタイムに型チェックを厳格に行うことが可能
public function isTypeValid(mixed $input): bool {
// reify された T に対して直接 is 演算子が使える！
return $input is T;
}
}
function handleReifiedBox(ReifiedBox
// JITコンパイラは、この Box が「int」で具現化されていることを知っているため、
// getData() の戻り値に対する型ガードを完全に排除（Guard Elimination）できる。
$val = $box->getData();
}
`reify` を適用することで、HHVMのAOT（Ahead-Of-Time）コンパイラおよびJITは、コンパイル時にクラス固有の最適化パスを構築でき、C++のテンプレート特殊化に近い実行効率を達成する。
—
3. HHBC（HHVMバイトコード）レベルでの検証
リファクタリングがJITに与える影響を、HHBC（HHVM Bytecode）の観点から検証する。
例えば、`mixed` を用いた動的プロパティアクセスと、型安全な `shape`/`class` プロパティアクセスでは、出力されるバイトコードが劇的に異なる。
`mixed` でのメンバアクセス時（非効率）
CGetM
`CGetM` は、レジスタ上の値の型（`DataType`）を判定する巨大なスイッチ文を内部で実行するため、CPUの分岐予測（Branch Predictor）に深刻なダメージを与える。
Strictな型定義時（超効率）
CGetL
型が静的に解決されているため、HHVMはハッシュテーブルのルックアップを一切バイパスし、構造体の固定オフセット（メモリ上のアドレス `base_address + offset`）から直接値を読み出す超高速なアセンブリ命令を生成する。
—
4. 終わりに：アーキテクトとしての決断
レガシーPHPコードベースをHackへと移行する真の目的は、「ただコンパイラのエラーを消すこと」ではない。HHVMという希代の実行エンジンが持つポテンシャルを100%解放することにある。
コードベースに `mixed` を残すということは、JITコンパイラに対して「私たちは最適化を望んでいません」と宣言しているに等しい。
1. 境界に型を定義せよ（`shape` と `Strict Mode` の適用）
2. 動的キャスト（`as`）は最小限に留め、`is` による型洗練でJITの実行パスを最適化せよ
3. ジェネリクスには `reify` を与え、ランタイムの型消去を克服せよ
このロードマップに従い、コードベースから1つずつ `mixed` を駆逐していくことで、システムのメモリ使用量は劇的に削減され、スループットは極限まで向上する。型安全性とは、究極のパフォーマンス最適化技術なのである。