Readonlyの深淵：HHVMのJIT最適化を極限まで引き出す「制約」の魔術
Hackにおける`readonly`修飾子は、単なる「値の書き換え防止」というレベルの低い安全装置ではない。これは、HHVMのJIT（Just-In-Time）コンパイラが抱える「エイリアス解析の苦悩」を解消し、実行時のメモリレイアウトを静的に固定するための、極めて強力な最適化のヒントである。
本稿では、`readonly`が単に型安全性を高めるだけでなく、HHVMのランタイムにおいていかにして「不変性（Immutability）」を保証し、それがJITによるコード生成にどのような恩恵をもたらすのかを、深層から解説する。
—
1. 破壊的代入が招く最適化の「死角」
通常のMutableなオブジェクトにおいて、プロパティへのアクセスは常に「その値が書き換わっている可能性」を考慮しなければならない。JITコンパイラがプロパティの値をレジスタにキャッシュしようとしても、別のスレッドや別のメソッド呼び出しによって値が変更されるリスクがあるため、常にメモリアクセスを伴うロードが発生する。
これが、大規模な計算処理における最大のボトルネックとなる。
// 通常のクラス：コンパイラは「いつ値が変わるか」を厳密に追跡する必要がある
class MutablePoint {
public float $x;
public function __construct(public float $y) {}
}
// JITは $p->x の値をキャッシュしたくても、
// 別の箇所で書き換えられるリスクを排除できないため、メモリアクセスを強制する
2. Readonlyによる「不変性」の保証とJITの解放
`readonly`を付与した瞬間、コンパイラは「このメモリ領域は初期化後、二度と書き換わらない」という強力な仮定を置くことができる。これは、プロパティが「定数に近い存在」として扱われることを意味する。
HHVM内部での最適化の連鎖
1. エイリアス解析の省略: `readonly`プロパティは「書き込み不可」であるため、依存関係の解析が不要になる。
2. レジスタ割り当ての最適化: メモリからロードした値を、関数のスコープ全体で汎用レジスタに固定配置できる。
3. インライン展開の加速: プロパティ読み取りが単なる定数参照に置き換わるため、メソッド呼び出しのオーバーヘッドが劇的に減少する。
readonly class ImmutablePoint {
public function __construct(
public float $x,
public float $y,
) {}
}
function calculateDistance(ImmutablePoint $p): float {
// $p->x と $p->y は定数としてレジスタに展開される可能性が高い
return \sqrt($p->x 2 + $p->y 2);
}
このコードにおいて、HHVMのJITは`$p->x`へのアクセスをメモリロードから即値への埋め込み、あるいはレジスタ参照へと最適化する。これは数百万回のループ処理において、キャッシュミスを削減し、CPUパイプラインを効率的に埋めるための決定的な要因となる。
—
3. 型チェッカーとランタイムの協調
Hackの型チェッカー（`hh_client`）は、`readonly`プロパティに対して厳格な制約を課す。これは単なる規約ではなく、HHVMが生成する機械語の「正当性」を担保するための前処理である。
もし`readonly`の不変性が破壊されるようなコードがあれば、コンパイル時にエラーを吐く。これにより、ランタイム側では一切の「書き換えチェック」を省くことができ、実行速度が最大化される。
厳格な型推論の活用例
readonly class Config {
public function __construct(public string $dbHost) {}
}
// 関数シグネチャでのreadonly指定
function process(readonly Config $c): void {
// $c->dbHostは、この関数の実行中に変更されないことが型システムで保証されている
// したがって、HHVMはこれをヒープメモリの固定オフセットとして読み取る
echo $c->dbHost;
}
—
4. なぜこれがアーキテクチャの未来なのか
高スループットなWebサービスにおいては、ガベージコレクション（GC）の負荷とメモリの局所性がパフォーマンスを決定づける。
`readonly`オブジェクトは、一度生成されると内部状態が変化しないため、「読み取り専用のメモリ領域」や「不変データ構造」としての活用が可能になる。これにより、HHVMのGCは「このオブジェクトは世代交代（Generational GC）においてスキャン不要である」と判断する最適化を導入しやすくなる。
極限の設計指針
- 状態の局所化: 変更が必要なデータは`readonly`の外に追い出し、ロジックの核心部は常に`readonly`クラスで構築する。
- コピー・オン・ライトの活用: `readonly`で構造を定義し、変化が必要な場合は新しいインスタンスを生成する（関数型アプローチ）。これはHHVMの効率的なメモリ管理と非常に相性が良い。
—
結論：型はパフォーマンスそのものである
Hackにおける`readonly`は、言語仕様上の「飾り」ではない。それは、CPUがプロセッサレベルで最適化を行うための、コンパイラからマシンへの強力なメッセージである。
我々アーキテクトが目指すべきは、型チェッカーを「ガードレール」として使うだけでなく、HHVMのJITエンジンを加速させるための「設計図」として使いこなすことにある。`readonly`を制する者は、HHVMのメモリレイアウトを制し、結果としてシステムの極限的なスループットを掌握する。
型を厳格に定義せよ。そして、その不変性を信じよ。コンパイラはその信頼に、計算速度という形で応えるはずだ。