不変性の深淵：`readonly`プロパティがHHVMのJIT最適化にもたらす「メモリバリア撤廃」の真実
Hackの進化の歴史は、動的型付け言語の柔軟性を捨て、いかにして「静的解析の限界」を押し広げるかの戦いだった。その中でも、近年の導入された `readonly` プロパティは、単なるプログラミング上の制約ではない。これは、HHVMのJITコンパイラが長年抱えてきた「エイリアス解析（Alias Analysis）」という聖域に対する、極めて強力な最適化のトリガーである。
なぜ `readonly` が実行速度に直結するのか。その深層には、CPUのパイプラインとメモリモデルの残酷なまでのリアリズムがある。
—
1. 破壊的代入が招く「メモリバリア」の悲劇
一般的なオブジェクトのプロパティは、実行時のいかなるタイミングでも書き換えが可能だ。これはプログラマには便利だが、JITコンパイラにとっては悪夢である。
あるオブジェクト `$obj->x` を読み込み、その直後に別の関数呼び出し `do_something()` を経て、再度 `$obj->x` を読み込むコードを考えてみよう。
// 通常のプロパティの場合
$val1 = $obj->x;
do_something();
$val2 = $obj->x; // JITはここをキャッシュできるか？
JITの視点から見れば、`do_something()` の内部で、あるいはその先で `x` が書き換えられている可能性を否定できない。そのため、JITは「`x` は不変ではない」という前提に立ち、`do_something()` の後に必ずメモリからの再ロードを強制する。
さらにマルチスレッド環境や複雑なオブジェクトグラフでは、メモリの整合性を保証するために、コンパイラはメモリバリア（Memory Barrier / Fence）を挿入せざるを得ない。これはCPUのロード・ストアの順序を強制する命令であり、パイプラインのストールを招く。
2. `readonly` による静的保証：JITの「推論」からの解放
`readonly` プロパティが宣言された瞬間、Hackの型チェッカーはその値を「コンパイル単位での不変性」として確定させる。HHVMのJITコンパイラにおいて、これは極めて強力なヒントとなる。
class Container {
public readonly int $x;
public function __construct(int $x) { $this->x = $x; }
}
JITコンパイラはこのメタデータを読み取った瞬間、生成されるマシンコードから以下のような冗長な命令を削除する。
1. 冗長なロード（Redundant Load）の削除:
一度レジスタにロードした値は、プロパティが `readonly` である限り、そのオブジェクトのライフサイクルを通じて同一であることが保証される。JITは「再ロード」の命令を破棄し、レジスタ上の値を使い回す。
2. メモリバリアの除去:
値が変化しない以上、同期のためのフェンスを張る必要はない。CPUは予測実行（Speculative Execution）をより深く、アグレッシブに行うことができるようになる。
3. レジスタ割り当ての最適化とレイテンシの改善
`readonly` を活用することで、HHVMのグローバル最適化パスは、オブジェクトグラフをよりフラットな構造として捉え直す。
- インライン展開の促進: `readonly` プロパティへのアクセスは定数と同等の扱いを受けるため、関数インライン化のコストが大幅に下がる。プロパティ参照が「メモリ操作」ではなく「レジスタ操作」に格上げされるからだ。
- 逃げ出し解析（Escape Analysis）との共鳴: オブジェクトが関数外に逃げ出さないことが判明している場合、`readonly` プロパティはスタック上の値として最適化され、ヒープアクセスすら完全に消滅する可能性がある。
4. アーキテクトへの提言：性能を限界まで引き出すために
我々がコードを書く際、単に「型が合っている」だけで満足してはならない。システムアーキテクトとして意識すべきは、「JITコンパイラにどれだけ迷いを捨てさせるか」である。
以下のプラクティスを遵守せよ：
- 初期化後の変更が不要なら、迷わず `readonly` を付与せよ: これはパフォーマンスの最適化であると同時に、データ競合を防ぐセキュリティ上の防御策でもある。
- 不必要なカプセル化（Getterの乱用）を避ける: Hackでは `readonly` プロパティへの直接アクセスは十分に高速だ。無意味なゲッターによるメソッド呼び出しのオーバーヘッドは、JITによるインライン化の障壁になることもある。
- 大規模データ構造の設計: 不変なプロパティを構造体の中心に据えることで、オブジェクト間の依存関係をグラフ理論的に簡素化できる。これにより、HHVMのガベージコレクタ（GC）の追跡対象が減り、メモリレイテンシも改善される。
結論
`readonly` は単なる不変性の宣言ではない。それは、VMがメモリの「不確実性」から解放されるための鍵である。
HHVMという巨人が、予測実行という牙を剥き出しにして爆速で動作するためには、我々エンジニアが「このメモリ領域は決して裏切らない」という静的な約束を、型システムを通じてコードに刻み込む必要がある。型システムを愛せ。型システムは、あなたのコードがマシン上でどのように踊るかを決定する、最も根源的な地図なのだから。