破壊的変更の終焉：Hackの`readonly`がHHVMのJITを「覚醒」させるメカニズム
コードレビューで「なぜこのプロパティを`readonly`にしないのか？」と問うとき、私は単に安全性を求めているのではない。私は、HHVMという猛獣がその牙（JITコンパイラ）を最大限に剥き出しにするための「確証」を求めているのだ。
Hackの`readonly`修飾子は、単なる型システム上の制約ではない。それはHHVMに対して「このメモリ領域のセマンティクスは決して変化しない」という強力な契約を突きつける行為だ。この契約が、いかにしてメモリバリアを消し去り、CPUのパイプラインを劇的に加速させるのか。その深淵を解き明かそう。
—
1. なぜ「可変性」はJITの敵なのか
通常のクラスプロパティが可変（mutable）であるとき、JITコンパイラは常に「この値は別のスレッドや別のメソッドによって、いつ何時書き換えられるか分からない」という前提でコードを生成しなければならない。
結果として発生するのが、メモリバリア（Memory Barrier）の挿入だ。
CPUはキャッシュの一貫性を保つため、値の読み出しのたびに「メモリは最新か？」「他のコアで書き込みが行われていないか？」を確認する。これは現代のマルチコアCPUにおいて、極めて重いオーバーヘッドとなる。
readonlyがもたらす最適化の正体
プロパティを`readonly`にすると、HHVMは以下の最適化を確信を持って実行できる。
- ロードの折り畳み（Load Hoisting）： プロパティをレジスタに一度ロードすれば、二度目以降のアクセスではメモリを参照する必要がない。コンパイラは「値が変わらない」ことを知っているため、何度でもそのレジスタを再利用できる。
- メモリバリアの排除： 読み込み時に「他者による書き込み」を考慮する必要がないため、同期のための命令が消滅する。
- インライン展開の促進： 状態が変わらないことが保証されれば、Getterメソッドなどは即座に定数値としてインライン展開の候補となる。
—
2. 実践：パフォーマンスを最大化する「堅牢なDTO」設計
単なるデータの器（DTO）であっても、書き方次第でHHVMの挙動は変わる。以下のコードを見てほしい。
namespace App\Domain;
/
readonly を活用した、メモリ効率と堅牢性を両立するDTOの例
/
final class UserContext {
// readonly を付与することで、JITは内部的にこのプロパティを
// クラスインスタンスの定数オフセットとして固定する
public function __construct(
public readonly int $id,
public readonly string $email,
public readonly bool $isVerified,
) {}
// readonlyにより、このメソッドは事実上の定数参照となり、
// インライン化の際、関数呼び出しコストがほぼゼロになる
public function getSummary(): string {
return sprintf(“User[%d]: %s”, $this->id, $this->email);
}
}
なぜこの設計が最強なのか
1. `final`クラスとの相乗効果： `final`を付与することで、HHVMはクラスの継承ツリーを確定させる。`readonly`プロパティとの組み合わせにより、プロパティアクセスの命令は単なる「ポインタ＋オフセット」の固定命令へと変換される。
2. 不変性の伝播： このオブジェクトを別のコンポーネントに渡しても、値が汚染される心配がない。これは「防衛的コピー（Defensive Copy）」を不要にし、不要なメモリ割り当てを削減する。
—
3. 実務で「やってはいけない」アンチパターン
多くのエンジニアが陥る罠は、「とりあえず`readonly`を付ければ速くなる」と信じて、Getterだらけのコードを書くことだ。
// 非推奨：過度なカプセル化は、不適切な抽象化を招く
class BadPattern {
private readonly int $val;
public function __construct(int $v) { $this->val = $v; }
public function getVal(): int { return $this->val; } // 無意味なラッパー
}
JITの観点から見れば、`readonly public`プロパティを直接公開する方が、メソッド呼び出しのオーバーヘッドを排除でき、且つ型安全も保証される。「不変性」を確保しているなら、カプセル化の壁を作る必要はない。 隠蔽と公開のトレードオフを再考せよ。
—
4. チーフアーキテクトからの提言
Hackの型システムは、あなたのコードを「より正しく」するだけではなく、「より速く」するためのコンパイラへのヒントだ。
- 意識改革： `readonly`を単なる「読み取り専用制限」と捉えるな。あれは、コンパイラに対する「このメモリ領域の論理的一貫性を保証するから、お前は全力で最適化せよ」という最適化のトリガーである。
- 設計の指針： コンポーネント間でデータをやり取りする際は、可能な限り`readonly`プロパティを持つイミュータブルなオブジェクトを使え。これにより、非同期処理におけるデータ競合の不安から解放され、かつJITが最高効率で動作する環境が整う。
Hackは、怠惰なコードを許容しない。しかし、正しく理解し、型と制約を使いこなす者には、現代のWeb環境において最高速の実行性能という報酬を与える。
さあ、コードを開いて、`readonly`を付与すべき場所を探しに行こう。その一行が、あなたのアプリケーションのCPU負荷を少しだけ減らし、ユーザー体験を一段階引き上げるはずだ。