破壊的変更の終焉：Hackにおける`readonly`と不変性のアーキテクチャ
大規模なHHVMエコシステムにおいて、バグの最大の温床は「意図しない状態の変異（Mutation）」にある。並行処理が当たり前の現代において、共有メモリの可変性はもはや負債でしかない。
今日は、Hackの`readonly`修飾子が単なるシンタックスシュガーではなく、コンパイラとHHVMランタイムがどう連携し、メモリレイアウトの最適化とスレッド安全性を担保しているのか、その深淵を紐解く。
—
1. `readonly`の真髄：型推論を超えたメモリ境界の定義
Hackの`readonly`は、単にプロパティへの代入を禁止するだけの制約ではない。これは「型システムのガードレール」であり、コンパイル時にメモリの所有権とアクセス権を静的に分離するための基盤だ。
通常のクラスプロパティはヒープ上の可変領域を指すが、`readonly`を付与した瞬間、HHVMのJITコンパイラはそれを「初期化以降、不変である」という前提で最適化をかける。
<<__ConsistentConstruct>>
final class UserSession {
// readonlyにより、コンストラクタ終了後の変更をコンパイラが完全に遮断する
public readonly int $userId;
public readonly string $token;
public function __construct(int $id, string $t) {
$this->userId = $id;
$this->token = $t;
}
}
なぜこれが重要か？
HHVMのアーキテクチャにおいて、`readonly`が指定されたプロパティは、JITによるコード生成時、`Stk`（スタック）やレジスタへのロードがより積極的に行われる。コンパイラは「この値は決して変わらない」と知っているため、メモリからの再ロードをスキップし、定数としてインライン化する最適化パスを適用できるのだ。
—
2. 不変データ構造の強制とHHVMのメモリ管理
不変（Immutable）なデータ構造を強制することの最大の恩恵は、「防御的コピー（Defensive Copy）」からの解放にある。
通常、可変オブジェクトを関数の引数として渡す際、副作用を恐れてプログラマはオブジェクトをクローンする。だが、`readonly`プロパティを持つオブジェクトであれば、その必要はない。参照を渡すだけで、呼び出し先がその状態を壊すことができないと静的解析で保証されているからだ。
メモリ効率のパラドックス
シニアエンジニアなら理解できるはずだ。不変性を強制することは、一見メモリ消費を増やすように見えるかもしれない。しかし、実際には「コピー・オン・ライト」や「オブジェクトの共有」が可能になるため、ヒープ上のインスタンス数は劇的に減る。
// readonlyプロパティを用いた状態遷移の設計
readonly class Config {
public function __construct(
public readonly int $maxRetries,
public readonly float $timeout,
) {}
}
// 変更が必要な場合は、新しいインスタンスを生成する（Functional Update）
function updateTimeout(Config $c, float $newTimeout): Config {
return new Config($c->maxRetries, $newTimeout);
}
この設計により、HHVMは複数のスレッドや非同期コンテキスト間で同一の`Config`インスタンスを安全に共有できる。これはメモリフットプリントを最小化する究極の戦略だ。
—
3. コンパイラによる厳格な型チェックの深層
Hackの型チェッカー（`hh_client`）は、`readonly`プロパティが構築された後の変更を許さない。もしこれが破られれば、コンパイルエラーを吐き出し、バイナリ生成を停止する。
重要なのは、これがランタイムチェックではなくコンパイル時チェックであるという点だ。HHVMの仮想マシン実行時に`readonly`のチェックを行う必要はない。つまり、パフォーマンス上のオーバーヘッドは「ゼロ」である。
セキュリティ研究者への視点
セキュリティの観点からも、`readonly`は「型安全な定数」として機能する。例えば、認証トークンや設定データが、実行中にメモリ破壊攻撃や意図しないプロパティの書き換えによって改ざんされるリスクを、言語レベルで完全に排除できる。
—
結論：コードは「意図」を語るべきだ
Hackにおける`readonly`修飾子の導入は、単なる機能追加ではない。それは「変更可能な状態を排除し、システムの推論可能性を高める」という、エンジニアリングにおける哲学の強制である。
1. 静的解析によるゼロコストの安全性
2. JIT最適化による定数インライン化の恩恵
3. データ共有によるメモリ効率の最大化
これらを武器に、君たちが開発するシステムを、予測不能なバグから解放せよ。コードの不変性は、大規模システムの安定性という名の「魂」そのものだ。
次にコードを書くとき、`public`を記述する指を止め、一度考えてみてほしい。「これは本当に変更される必要があるのか？」と。その問いこそが、熟練のアーキテクトへの第一歩である。