【テクニカル・上級編】『Partial Mode』から『Strict Mode』への移行：段階的リファクタリングのロードマップ – Hack言語 コア・静的型システムとHHVMのアーキテクチャ解析バイブル

JITコンパイルとメモリ効率の差

Strict Modeがもたらす最大の恩恵は、可読性ではない。「ポインタのアンボクシング（Unboxing）」と「ディスパッチの静的解決」によるメモリフットプリントの削減とスループットの向上だ。

Partial Modeでは、値がプリミティブ（`int`, `float`, `bool`）であるか、あるいはヒープ上のオブジェクトであるかが実行時まで確定しないため、HHVMは値の型タグを保持するプレースホルダー（Tagged Union）を多用する。これはメモリのキャッシュ効率（L1/L2キャッシュミス）を悪化させ、不要なガベージコレクションの負荷を生む。

一方、Strict Modeで書かれたコードは、型チェッカーの保証のもとでバイトコードジェネレータが直接ネイティブのレジスタ操作にマッピング可能な命令を出力できる。プロパティアクセスにおける `Prop` バイトコードのオーバーヘッドは消滅し、Vtableを介さない直接的なメソッド呼び出し（Direct Call）へと最適化されるのだ。

—

2. 段階的移行における現実の罠：暗黙の `mixed` との戦い

大規模コードベースをStrict化する際、最大の障害となるのは「どこから手をつけるべきか」という依存関係のループである。

依存関係の底辺（他のどのクラスにも依存しないリーフノード：Value ObjectやDTO）からStrict化していくのが定石だが、Partial ModeのコードからStrict Modeのコードを呼び出す際、あるいはその逆の境界線で、HHVMは厳格な境界チェックを行う。

移行期によくあるアンチパターン

焦るあまり、型エラーを回避するために `mixed` や不必要なキャスト（HH\Asio\… などでの無理な型アサーション）を多用する開発者がいる。これは最悪の選択だ。`mixed` を残したままStrict化しても、それは「型安全なふりをした動的コード」にすぎず、JITの最適化恩恵を全く受けられないどころか、型チェッカーの解析コストだけが増大する。

—

3. 実践：段階的リファクタリングのロードマップとコード戦略

ここからは、実戦で使える具体的な移行ステップをコードベースのレイヤ構造とともに示す。

ステップ1: `.hhconfig` による段階的な強制と警告の分離

一気に全体をStrictにするのではなく、ディレクトリ単位、あるいはファイル単位で型チェックの厳格度をコントロールする。`.hhconfig` や個別のファイルヘッダーを活用する。

移行初期のコードベースでは、既存の型エラーを無視しつつ新規コードや特定モジュールだけをStrictにするアプローチが必要になる場合がある。しかし、最終目標は全てのファイルを `ステップ2: 境界領域（Boundary）の型安全化

リファクタリング対象のモジュールが、外部のレガシーなPartial Modeコードや外部API（JSONデシリアライズなど）と通信する境界では、「Runtime Type Assertions（ランタイム型アサーション）」を厳密に行う必要がある。

以下のコードは、Partial Modeの汚染を断ち切り、Strict Modeの世界へ安全にデータを持ち込むためのパターンだ。

/
final class UserPayloadHydrator
{
/

• mixedな入力データを解析し、厳格な型を持つ構造体を返す。
• ここで実行時型チェックを行うことで、Strictコード内の安全性を担保する。

/
public static function hydrate(mixed $raw_data): UserDto
{
// 厳格な形状（Shape）チェックを強制
invariant(
is_array($raw_data),
‘Payload must be an array, %s given.’,
gettype($raw_data)
);

// キーの存在と型の検証
$id = $raw_data[‘id’] ?? null;
$name = $raw_data[‘name’] ?? null;

// プリミティブ型への厳密なキャストと検証
invariant(
is_int($id) && $id > 0,
‘Invalid or missing user ID.’
);
invariant(
is_string($name) && C\strlen($name) > 0,
‘Invalid or missing user name.’
);

return new UserDto($id, $name);
}
}

final class UserDto
{
public function __construct(
public int $id,
public string $name,
) {}
}

ステップ3: コレクションの具象化とジェネリクス（Generics）の完全適用

Partial Modeでは `array`（ハッシュマップとベクターが混在したHHVM固有の緩い配列）が多用される。これをStrict Modeへ移行する際は、`Vector`, `Map`, `ImmMap` などのimmutable/mutableコレクションへ置き換える。

これにより、HHVMのメモリマネージャは配列の動的なハッシュ再構築コストを排除し、連続したメモリ領域へのアロケーション最適化を行うことが可能になる。

> $rolePermissions;

public function __construct(darray> $raw_config)
{
$builder = Map {};
foreach ($raw_config as $role => $permissions) {
// vec から ImmSet への変換時に型が完全に保証される
$builder[$role] = ImmSet::fromItems($permissions);
}
$this->rolePermissions = $builder->immutable();
}

public function hasPermission(string $role, string $permission): bool
{
$perms = $this->rolePermissions->get($role);
if ($perms === null) {
return false;
}
return $perms->contains($permission);
}
}

—

4. チーフアーキテクトからの提言：移行完了の判定基準

移行作業が順調に進んでいるかを判断する基準は、単に `hh_client` がエラーを吐かなくなったことではない。

1. ダイナミックコール（Dynamic Calls）の完全排除: `hh_server` のメトリクスまたはコンパイルログにおいて、動的メソッド呼び出しやプロパティ動的アクセスの警告がゼロになっていること。
2. JITのネイティブコード生成率の向上: HHVMのパフォーマンスプロファイラを用い、TC（Translation Cache）内での型ガード起因によるスローパス（Slow Path）の実行頻度が低下していることを確認する。
3. CI/CDパイプラインでの厳格化: プルリクエストごとに `hh_client` を実行し、1つの型エラーもマージされない政治的・技術的合意がチーム全体に浸透していること。

静的型付けは、単なる「バグを防ぐための教条主義」ではない。それは、仮想マシンに対して「このメモリ領域の構造は絶対に変化しない」というハードウェア最適化のための強固な契約（Contract）を突きつける行為なのだ。

妥協のないコードベースこそが、極限の負荷に耐えるシステムを形作る。今日からでも、その最初の `