不変データの強制：Hackの `readonly` と不変コレクションがHHVMのメモリ空間をも変える理由
長年、PHPエコシステムからの進化の歴史を見つめてきた者にとって、Hack言語が到達した厳格な静的型付け（Strict Mode）と不変性（Immutability）の統合は、単なる「バグを防ぐためのシンタックスシュガー」ではない。それは、HHVM（HipHop Virtual Machine）のランタイム最適化、CPUキャッシュ効率、そして並行分散処理におけるデータ整合性のパラダイムシフトそのものである。
本稿では、中級からシニアへのステップアップを見据えるエンジニアに向け、Hackにおける `readonly` プロパティと不変コレクション（Immutable Collections）が、コンパイラと仮想マシンの内部でいかに振る舞い、いかにして副作用を根絶するのかを、低レイヤの視点から解き明かす。
—
1. なぜ「副作用」は悪なのか：ランタイムと型チェッカーの視点
大規模なコードベースにおいて、予期せぬ状態変化（Mutation）はバグの温床であり、セキュリティ脆弱性の入り口となる。オブジェクトがどこで誰によって書き換えられるか分からない状態（Shared Mutable State）は、マルチスレッドや非同期処理への移行を阻む最大の障壁だ。
Hackは、`<<__STRICT__>>` モードの下で、型チェッカー（hhvm）に厳格な解析を義務付ける。しかし、型が合っているだけでは「参照の共有による意図しない書き換え」を防ぐことはできない。ここで登場するのが 不変性（Immutability）の強制 である。
Hackの不変性は、単にプログラマの規律に頼るものではない。型チェッカーによる静的検証 と HHVMの低レイヤメモリ管理 が一体となって初めて成立する、ハードコアな制約なのだ。
—
2. `readonly` プロパティ：コンパイル時不変性の極限
Hackにおける `readonly` 修飾子は、プロパティが初期化（通常はコンストラクタ内）された後、二度と値を変更できないことを静的に保証する。
<<__STRICT__>>
namespace Hack\Engine\Excellence;
class ImmutableServerConfig {
// readonlyプロパティの宣言。コンストラクタ外からの代入は型チェッカーにより即座にコンパイルエラーとなる。
public function __construct(
public readonly string $host,
public readonly int $port,
public readonly vec
) {}
}
HHVM内部での `readonly` の挙動
動的言語の系譜を持つ言語において、プロパティの書き込みガードを動的に行うオーバーヘッドは無視できない。しかし、HHVMのJITコンパイラ（RepoAuthoritativeモードなど）にとって、`readonly` の付与されたプロパティは 「不変である（Immutable）」という強力な最適化ヒント となる。
1. インラインキャッシュの最適化: プロパティアクセスにおいて、HHVMはそれが変化しない前提でプロパティオフセットのキャッシュやメモ化をアグレッシブに行うことができる。
2. 書き込みバリアの排除: GC（ガベージコレクタ）や世代別ヒープ管理において、不変オブジェクトへの参照変更が発生しないことが保証されている場合、不要なライトバリア（Write Barrier）の生成を抑制できる。
—
3. 不変コレクション（`ImmVector`, `ImmMap`, `ImmSet`）の内部構造
プリミティブな配列や通常の `Vector`、`Map` はミュータブル（可変）であり、関数間で渡された際に防衛的コピー（Defensive Copy）を行わない限り、どこかで値が書き換えられるリスクを孕む。
Hackは、明確に分離された不変コレクションを提供する。これらは、単に「書き込みメソッドが存在しない」だけでなく、メモリ上のレイアウトそのものが最適化されている。
<<__STRICT__>>
namespace Hack\Engine\Excellence;
class RequestProcessor {
// 不変マップを受け取ることで、呼び出し元での意図しない変異を完全に遮断
public function __construct(
private readonly ImmMap
) {}
public function getHeader(string $name): ?string {
// ImmMapの参照をそのまま返しても、内部データが破壊される心配はない
return $this->headers->get($name);
}
}
コピー・オン・ウライト（CoW）とメモリ効率
HHVMのコレクションは、内部的に高度なデータ構造（HAMT: Hash Array Mapped Trieなど）をベースに構築されていることが多く、不変コレクション同士の変形（例：`ImmMap::set()` のような操作、実際には新しいインスタンスを返す操作）において、可能な限り既存のメモリノードを共有する構造をとる。
これにより、防衛的コピーによるメモリ帯域の圧迫を防ぎつつ、完全な関数型プログラミングのセマンティクス（参照透過性）を維持することが可能になる。
—
4. 実践：副作用を完全に排除したドメインモデルの設計
ここでは、`readonly` と不変コレクションを組み合わせ、外部からの介入を完全に遮断した堅牢なドメインモデルの実装例を示す。
<<__STRICT__>>
namespace Hack\Engine\Excellence;
class Transaction {
public function __construct(
public readonly string $id,
public readonly float $amount,
public readonly ImmVector
) {}
/
- 状態を変更する代わりに、新しい不変インスタンスを生成して返す（Functional Update）。
/
public function appendAudit(string $entry): this {
// ImmVectorのbuilder、あるいはラップ操作により新しいImmVectorを生成
$newTrail = ImmVector::concat($this->auditTrail, vec[$entry]);
// クラス自体がreadonly風、あるいはイミュータブルであれば new static で返す
return new static(
$this->id,
$this->amount,
$newTrail,
);
}
}
型チェッカーがもたらす安全網
もし開発者がうっかり以下のようなコードを書いたとしよう。
function corrupt_data(Transaction $tx): void {
// コンパイルエラー: Cannot modify a readonly property Transaction::$amount
$tx->amount = 1000.0;
}
HHVMの型チェッカーは、このコードをランタイムに到達させることなく、ビルドパイプラインの静的解析段階で即座に検出し、異常終了させる。この「フェイルファスト」の思想こそが、大規模コードベースの破綻を防ぐ唯一の盾である。
—
5. チーフアーキテクトからの提言：パフォーマンスと設計のトレードオフ
「すべてを不変にすれば良い」というわけではない。高頻度で微小な更新が発生するホットスポット（例えば、大量のループ内で数値をインクリメントするような処理）において、毎回新しい不変オブジェクトや不変コレクションを生成することは、アロケーションのオーバーヘッドを増やし、GCの負担を高める結果になり得る。
極限のパフォーマンスを引き出すための指針:
1. 境界（Boundary）での不変化: アプリケーションの境界（HTTPリクエストの入力、外部APIレスポンス、データベースからのHydration）でデータを即座に `readonly` および不変コレクションに変換せよ。
2. ドメインロジック内での閉じたイミュータビリティ: ビジネスロジックの中核（コアエンジン）においては、ミュータブルな状態を一切排除し、完全な参照透過性を保て。
3. ホットループの最適化: 限界まで速度が求められる局所的な演算においては、明示的なミュータブルスコープ（ローカル変数としての可変配列など）を限定的に使用し、関数から外へ漏れ出させない設計をとれ。
Hackの静的型システムとHHVMのアーキテクチャは、プログラマが「意図した通りのコード」を書くための強力な物理法則を提供する。その法則を正しく理解し、使いこなすことこそが、真にスケーラブルで堅牢なシステムを構築する唯一の道である。