Hackの不変性（Immutability）とJIT：readonlyプロパティがメモリバリアを削減する仕組み
HHVM（HipHop Virtual Machine）の内部構造、とりわけJITコンパイラの最適化パスの限界を知る者であれば、「不変性（Immutability）」が単なるコードの保守性やバグ防止のためのイデオロギーではないことを理解しているはずだ。それは、ハードウェアの物理的制約、すなわちCPUキャッシュのコヒーレンシとメモリバリアのオーバーヘッドをバイパスするための、極めてアグレッシブなコンパイラ最適化のトリガーである。
Hack言語における `readonly` プロパティの導入は、PHP由来の動的なセマンティクスを引きずるRuntimeに対し、型チェッカーの静的保証をベースにした「ハードな不変性」を持ち込むものだ。この仕様がHHVMのJITエンジンにおいて、どのようにメモリバリアを消去し、ネイティブ実行速度の限界を突破するのか。その深淵なるメカニズムをコードとランタイムの挙動から解き明かす。
—
1. 動的言語の呪縛：なぜ通常のプロパティアクセスは重いのか
伝統的なPHP、そして型制約が緩い動的言語のランタイムでは、オブジェクトのプロパティ読み書きは、ハッシュテーブルのルックアップまたはオフセットベースであっても「いつでも書き換えられ得る（Aliasing & Mutation）」という前提でコンパイルされる。
HHVMのJIT（Translator – x64 / TC）は、プロパティへのアクセスが発生するたびに、以下のコストを支払っている。
1. 型ガード（Type Guard）の検証: プロパティの値が実行時に変化している可能性があるため、レイアウトの変化や型の遷移を常に監視する必要がある。
2. メモリバリア（Memory Barrier / Fence）: マルチスレッド環境や、非同期的な参照の書き換えを想定し、CPUのOut-of-Order実行やストアバッファのフラッシュを強制される。
3. レジスタアロケーションの破綻: あるメソッドのスコープ内でプロパティの値をレジスタにキャッシュしておいたとしても、途中の任意のメソッド呼び出し（Side Effect）によって「そのプロパティが別コンテキストから書き換えられたかもしれない」と仮定せざるを得ない。結果として、ロード命令（`MOV`）がループや連続処理の度に発行される。
この「不確実性」こそが、JITコンパイラが機械語レベルでのアグレッシブなループアンロールやレジスタ化（Scalar Replacement of Aggregates）を行えない最大のボトルネックである。
—
2. Hackの `readonly` がもたらす静的保証のパラダイムシフト
Hackの `readonly` 修飾子は、単に「外部から値を書き換えられない」という糖衣構文ではない。これは、型チェッカー（hhvm typechecker）からJITの最適化パイプラインに至るまで、「このメモリ領域は、生成された後に二度と変化しない（Write-Once, Read-Many）」という動かすことのできない不変の契約（Invariant）を強制する。
以下のHackコードを見てほしい。
<
namespace HackJITDemo;
readonly class Vector3D {
public function __construct(
public readonly float $x,
public readonly float $y,
public readonly float $z,
) {}
public readonly float function lengthSquared(): float {
// readonly コンテキスト内での計算
return $this->x $this->x + $this->y $this->y + $this->z $this->z;
}
}
function computeNorm(readonly Vector3D $v): float {
// $v は完全に不変であることが保証されている
return $v->lengthSquared();
}
このコードにおいて、`$v->x` などのプロパティは `readonly` として定義されている。型チェッカーは、このオブジェクトのライフサイクルを通じて、コンストラクターの実行完了後にこれらのプロパティを変更しようとするコードをコンパイルエラーとして弾く。
この静的保証がランタイムに伝播した瞬間、HHVMのJITコンパイラ（TC）の挙動が劇的に変化する。
—
3. JITコンパイルにおけるメモリバリアの削減と最適化メカニズム
HHVMのJITが `readonly` プロパティを持つオブジェクトをどのように扱うか、そのネイティブコード生成の裏側を覗いてみよう。
A. プロパティアクセスの「定数化（Constant Folding）」とレジスタ常駐
通常のオブジェクトプロパティアクセスは、オブジェクトのヒープアドレスからオフセットを計算してロードする命令（`movq offset(%rdi), %rax`）が必要になる。しかし、`readonly` プロパティの場合、JITはそれを「定数」あるいは「イミュータブルなスロット」として扱う。
もしオブジェクト自体がローカルスコープ内で生成され、その参照が外部に漏れていない場合（Escape Analysisの成功）、JITはプロパティのロード命令そのものを削除し、コンパイル時または初回ロード時のレジスタ値をそのまま再利用する。
B. メモリバリア（Load Fence / Store Barrier）のパージ
マルチコアプロセッサ上で動作する仮想マシンは、あるスレッドで行われたメモリの書き込みが、別のスレッドからどのように観測されるかを保証するためにメモリバリア命令（例: x86の `MFENCE` や、ストア/ロード間の順序保証）を挿入する。
しかし、データが `readonly` であると宣言されている場合：
- ストア側の懸念がゼロになる: 初期化フェーズを除き、このメモリ領域に対する `Store` 操作が発生しないことが静的に保証されるため、コンパイラは後続のロード操作に対するバリア（Load-Load fence等）を一切挿入する必要がなくなる。
- CPUのパイプラインは、キャッシュヒットした不変データを何の躊躇もなく投機的実行（Speculative Execution）のパイプラインに載せることができる。
C. 実際のJIT IR（Intermediate Representation）のイメージ
HHVMのトランスレータが内部で使用するIRレベルでの比較を示す。
通常プロパティのアクセス（IR）:
(ObjPropRead) t1 = LoadObjProp $obj, offset_x
(MemoryBarrier) FenceLoad
(Use) t2 = Mul t1, t1
`readonly` プロパティのアクセス（IR）:
(ImmutableRead) t1 = LoadObjPropImmutable $obj, offset_x // バリア不要・レジスタキャッシュ可能
(Use) t2 = Mul t1, t1
この `LoadObjPropImmutable` は、JITの最適化パス（GVN: Global Value Numbering や Dead Code Elimination）において、冗長なロード命令の排除対象として極めて強力に作用する。ループの内部で `$v->x` が何回呼ばれようとも、JITはメモリへのアクセスを完全に排除し、単一のCPUレジスタ（例: `%xmm0`）への参照へとコンパイル結果を矮小化する。
—
4. 実戦的知見：イミュータビリティを極限まで活かすアーキテクチャ設計
シニアエンジニアやセキュリティ研究者であれば、この機構を最大限に引き出すためのコードパターンを設計に組み込むべきだ。
1. 巨大な設定データやドメインモデルの完全凍結
リクエストライフサイクルを通じて変化しない設定値や、イミュータブルな値オブジェクト（Value Object）は、すべて `readonly class` および `readonly` プロパティで定義する。
<
readonly class RequestContext {
public function __construct(
public readonly string $requestId,
public readonly Map
public readonly int $timestamp,
) {}
}
これにより、ミドルウェアやコントローラーの深部でコンテキストを参照する際のランタイムオーバーヘッドが実質ゼロになり、CPUキャッシュヒット率が極限まで高まる。
2. コレクションの不変性とHHVMの最適化
Hackのビルトインコレクション（`Vec`, `Dict`, `Keyset`）は、それ自体が値セマンティクス（Copy-on-Write）を持つが、`readonly` クラスのプロパティとして保持されることで、JITはそのコンテナの構造自体も不変であるとみなすことができる。
—
結び：ランタイムの物理限界に挑むプログラミング
Hackにおける `readonly` は、単なる静的解析のための安全弁ではない。それは、「開発者がコードの意図をコンパイラに極限まで正確に伝えることで、仮想マシンがハードウェアのポテンシャルを100%引き出すためのハイパフォーマンス・インターフェース」である。
動的言語の柔軟性を捨てず、しかしシステムプログラミング言語に匹敵するメモリ効率とJIT最適化の恩恵を引き出すこと。それこそが、HHVMとHackのアーキテクチャを掌握したエンジニアだけが到達できる極限の領域である。リファレンスをなぞるだけのコードから脱却し、ハードウェアの鼓動を感じさせるコードを書き下ろせ。