Hackの『不変性』が解き放つJITの真価：readonlyプロパティがメモリバリアを消し去る理由
Hack言語において、`readonly`プロパティは単なる「代入禁止の制約」ではない。これは、HHVMのJITコンパイラに対して我々プログラマが提示する「最適化のための最強のヒント」だ。
多くのエンジニアは「バグを防ぐために不変にする」と言う。だが、Core Committerの視点から言わせれば、「JITに推論の自由度を与えるために不変にする」のが正解だ。今日は、なぜ`readonly`がメモリバリアを削減し、CPUのパイプラインを劇的に加速させるのか、その深層を解き明かす。
—
1. JITの天敵：エイリアシングとメモリバリア
HHVMのJITエンジンは、実行時にバイトコードをマシン語に変換する際、究極の効率を求める。しかし、通常の可変プロパティには厄介な壁がある。それが「エイリアシング（Aliasing）」の懸念だ。
// 典型的な非効率コード
class User {
public int $points = 0;
}
function process(User $u): int {
$u->points = 10;
$val1 = $u->points; // JITは「この間に他から$u->pointsが書き換えられたか？」を疑う必要がある
// …何らかの処理…
return $val1 + $u->points;
}
このコードにおいて、JITは「`process`の途中で別スレッドや別の参照によって`$u->points`が変更されていないか？」という可能性を完全に排除できない。結果、JITはキャッシュされたレジスタ値ではなく、メモリからの再読み込み（Load）を強制される。これがメモリバリア（あるいはメモリフェンス）を誘発し、CPUの投機的実行を阻害する。
2. `readonly`による「不変の契約」がもたらす最適化
`readonly`を付与した瞬間、HHVMの型チェッカーとJITは、そのプロパティが「一度初期化されたら二度と変化しない」という絶対的な前提を保持できる。
readonly class User {
public function __construct(public int $points) {}
}
function process(User $u): int {
// JITは「$u->pointsは初期化以降絶対に変わらない」と断定できる
$val1 = $u->points;
// …何らかの処理…
// 以前の値をレジスタに保持したまま再利用できるため、メモリLoadをスキップ可能
return $val1 + $u->points;
}
JITは、`readonly`プロパティへのアクセスを「メモリ上の変数」ではなく「コンパイル時に確定した定数に近い存在」として最適化できる。結果、無駄なメモリバリアは消滅し、CPUはキャッシュミスを恐れずに命令を再順序付け（Out-of-order execution）できるのだ。
3. 実践：保守性とパフォーマンスを両立する設計パターン
実務において`readonly`を最大限に活かすなら、「値オブジェクト（Value Object）」の設計が不可欠だ。状態を更新したい場合は、内部プロパティを書き換えるのではなく、新しいインスタンスを生成する（いわゆるWitherパターン）。
readonly class Currency {
public function __construct(
public string $code,
public float $amount,
) {}
// 変更が必要な場合は新しいインスタンスを返す
public function withAmount(float $newAmount): this {
return new self($this->code, $newAmount);
}
}
// 利用例
function adjustBalance(Currency $c): Currency {
// 変更箇所が明確であり、かつコンパイラは不変性を保証できる
return $c->withAmount($c->amount 1.1);
}
この設計により、HHVMは`Currency`クラスのインスタンスを「完全に不変なブロック」として扱い、メモリ配置を最適化する。これは、非同期API連携で頻出する「複雑なレスポンスデータをスレッドを跨いで参照する」ようなケースにおいて、ロックフリーなデータ構造を構築するための強固な基盤となる。
4. チーフアーキテクトからの助言
多くのエンジニアは「不変にするとコピーが増えて遅くなる」と誤解している。だが、現代のHHVMのメモリ管理において、不変オブジェクトの生成と破棄コストは、可変オブジェクトの複雑な同期処理や再読み込みコストよりも圧倒的に軽い。
- `readonly`をデフォルトにせよ：設計段階で可変にする理由がない限り、すべて`readonly`で始めること。
- メモリバリアを意識せよ：頻繁にアクセスするプロパティほど、`readonly`化による恩恵が大きい。
- HHVMのJITグラフを信じよ：君たちが`readonly`と記述することは、HHVMのオプティマイザに対して「ここはもう推論しなくていい、全力で突っ走れ」という最高のパスポートを渡すことに等しい。
コードは「動く」だけでなく、「機械が読みやすい」ものでなければならない。`readonly`は、人間にとっての防弾チョッキであり、機械にとっての最適化の加速装置だ。今すぐリポジトリの全エンティティを見直し、`readonly`でコードを浄化せよ。それが、システムを次世代の速度へ導く唯一の道だ。