Hackの『Readonly』属性の真価：不変性の強制がもたらすHHVM最適化の深淵
Hack言語における `readonly` プロパティ。多くの開発者はこれを単なる「値の変更を禁止するアクセサ制限」程度の認識で捉えているかもしれない。だが、HHVMのアーキテクチャを知る者にとって、これは「ランタイムの推論コストを劇的に下げ、JITコンパイルの最適化を加速させるための強力なヒント」に他ならない。
なぜ、厳格な静的型付け（Strict Mode）において `readonly` がこれほどまでに重要なのか。その深淵に触れてみよう。
—
1. なぜ『Readonly』はJITにとって「聖域」なのか
HHVMのJITエンジンは、実行中のプロファイルに基づき、型や値の不変性を推論してネイティブコードを生成する。もしプロパティが変更可能であれば、JITは常に「どこかの誰かがこの値を書き換えているかもしれない」という可能性を考慮しなければならない。
- 従来の可変プロパティ: JITはアクセスするたびに、その値が別のスレッドやメソッドによって書き換わっていないかチェックを挟む必要がある。
- Readonlyプロパティ: 「一度初期化されたら二度と変わらない」という契約があることで、JITはプロパティの値をレジスタにキャッシュ（あるいは定数畳み込み）し続けられる。
この「推論の不確実性」を取り除くことこそが、大規模なデータ構造を扱う際、メモリレイアウトの最適化とCPUキャッシュ効率を最大化する鍵となる。
—
2. 実践：保守性とパフォーマンスを両立するデータ設計
単なるDTO（Data Transfer Object）も、`readonly` を活用することで、状態管理のバグを排除し、かつ実行速度を最適化できる。
以下のコードは、APIレスポンスを型安全かつ効率的に扱うための推奨パターンだ。
<<__ConsistentConstruct>>
final class UserProfile {
// コンストラクタでのみ代入を許可し、以降の変更を不可にする
public function __construct(
public readonly int $id,
public readonly string $username,
public readonly vec
) {}
// HHVMは、このクラスのインスタンスが渡されたとき、
// プロパティの再読み込みをせず、レジスタ上の値を利用する最適化を行える
}
final class UserProcessor {
public function process(UserProfile $user): void {
// readonlyにより、このメソッド実行中に $user->id が変更される可能性を排除。
// 副作用を気にせずロジックを記述できる。
echo “Processing user: {$user->username} (ID: {$user->id})\n”;
}
}
なぜこのコードが「美しい」のか
1. スレッドセーフな設計: `readonly` により、状態の不整合が構造的に防がれる。非同期API連携のコールバックなどでオブジェクトを渡す際、参照先の値が予期せず変わる恐怖から解放される。
2. 型チェッカーの恩恵: 代入しようとすれば即座に型チェックエラーとなる。バグをランタイムまで持ち込まないことが、最大のコスト削減だ。
3. HHVM最適化: `vec` や `dict` を持つクラスにおいて、プロパティが不変であることは、メモリ上のアライメント最適化を助ける。
—
3. 実務で陥る「アンチパターン」と回避策
エンジニアがやりがちなのが、`readonly` の使用を避けてゲッター（Getter）のみを実装することだ。
// 悪い例：ゲッターのみで制御しようとする
final class BadProfile {
private int $id;
public function getId(): int { return $this->id; }
}
このアプローチは、コード量が増える上に、JITコンパイラにとって「メソッド呼び出しのインライン化」という余計な推論コストを強いることになる。直接プロパティにアクセスする方が、圧倒的に効率が良い。 `readonly` を使えば、カプセル化を犠牲にすることなく、直接アクセスの安全性を保証できる。
—
4. 最後に：型とアーキテクチャを掌握する
Hackの厳格なモードにおいて、`readonly` はただの「書き込み禁止フラグ」ではない。それは、「このデータ構造は読み取り専用である」というメタデータをHHVMのエンジンに直接伝達するための言語仕様だ。
我々テクニカルリードが目指すべきは、単に動くコードを書くことではない。型チェッカーが静的に正当性を証明し、HHVMのJITがその構造の堅牢さを最大限に活用して高速な機械語を生成する――そんな「機械と人間双方にとって美しいコード」をデザインすることだ。
次のPRでは、君のクラス定義にある `private` プロパティを見直してほしい。そこに `readonly` を付与する勇気を持つだけで、君のプロダクションコードは一段上の高みへと昇華されるはずだ。