こんにちは！Hack言語の世界へようこそ。
他のプログラミング言語からやってくると、「おっ、Hackには `readonly` なんていう面白い修飾子があるんだな」と気づくはずです。
今回は、この `readonly` プロパティが、HHVM（HipHop Virtual Machine）のJIT（Just-In-Time）コンパイル構造やメモリ管理において、いかに強力な最適化をもたらしているのかを、熱く、そして分かりやすく紐解いていきますね。
ここをクリアすれば、あなたもHackのメモリモデルの深淵を覗くことができますよ。さあ、一緒にマスターしていきましょう！
—
1. Hackの `readonly` とは何か？（基本のおさらい）
まず、「不変性（Immutability）」について簡単におさらいしておきましょう。
現代のアプリケーション開発において、データが意図せず書き換えられてしまう「副作用（Side Effects）」は、バグの温床になりがちです。これを防ぐために、Hackではオブジェクトのプロパティを「読み取り専用」にする仕組みが用意されています。
基本の形を見てみましょう。
<<____FixMe>> // 便宜上のアノテーション省略
class UserSession {
// readonly修飾子がついたプロパティは、一度コンストラクトされると変更不可
public function __construct(
public readonly string $username,
public readonly int $loginTimestamp,
) {}
}
この `readonly` がついたプロパティは、コンストラクタの実行が終わった瞬間に「二度と書き換わらない絶対的な値」になります。外からうっかり `$session->username = “hoge”;` なんて書こうものなら、型チェッカーが即座に怒ってコンパイルエラーにしてくれます。
—
2. なぜ「不変性」がJITコンパイラを本気で喜ばせるのか？
さて、ここからが本題です。
「値が書き換わらない」という性質は、単にコードの安全性を高めるだけではありません。裏側でうごめく HHVMのJITコンパイラ にとって、この `readonly` は「最高のご馳走」なんです。
プログラミング言語のランタイムにおいて、「このメモリ領域の値は、将来絶対に変わらない」と言い切れることは、パフォーマンスを極限まで引き上げるための最大の武器になります。
メモリバリア（Memory Barrier）の呪縛
通常、マルチスレッドや複雑なオブジェクトグラフを持つVM（仮想マシン）において、CPUがオブジェクトのプロパティにアクセスするとき、JIT生成された機械語コードは「メモリバリア（Memory Barrier / フェンス）」という安全装置を挟む必要があります。
「他のスレッドがこの瞬間に値を書き換えていないか？」
「キャッシュの整合性は保たれているか？」
これを確認・保証するために、CPUレベルでメモリアクセスの順序を制御する命令が挿入されます。これが、ほんのわずかですが実行時のオーバーヘッドになります。
`readonly` がもたらす劇的な最適化
しかし、プロパティに `readonly` が付いている場合、HHVMのJITコンパイラはこう判断します。
> 「このメモリ番地の値は、生成された瞬間から死ぬまで不変だ。他のスレッドが書き換える余地すらない。だから、余計なメモリバリアやキャッシュ無効化の命令はすべてブッ飛ばして、CPUレジスタに直撃キャッシュしてしまおう！」
図解的に表現するなら、こうです。
[ 通常のプロパティアクセス ]
ポインタ取得 ➔ メモリバリア挿入 ➔ キャッシュ確認 ➔ 値の読み込み (重い)
[ readonly プロパティの JIT 最適化 ]
一度読んだ値をCPUレジスタに直置き ➔ 次回以降はバリアなしで一瞬でアクセス (爆速)
このメモリ操作の削減（メモリアセスのストリーム化）こそが、不変データ構造を積極的に使うべき最大の理由なのです。
—
3. 実践：readonly を活用した堅牢で速いコード
実際に、パフォーマンスと安全性を両立させるためのクラス設計を見てみましょう。
namespace HackMasterclass;
// 金融トランザクションデータを表すイミュータブルな構造
final class TransactionRecord {
public function __construct(
public readonly string $transactionId,
public readonly float $amount,
public readonly int $timestamp,
) {}
}
// 処理を行うサービス層
class TransactionProcessor {
public function process(TransactionRecord $tx): void {
// readonlyプロパティへのアクセスは、JITによって極限まで最適化される
echo “Processing TX: ” . $tx->transactionId . “\n”;
echo “Amount: ” . (string)$tx->amount . “\n”;
// 【エラーになる例】
// $tx->amount = 100.00;
// -> Hackのエラー: Cannot modify a readonly property
}
}
このコードでは、`TransactionRecord` が完全にイミュータブル保証されています。そのため、HHVMはこのオブジェクトを扱う際、安全性を担保しつつ、アグレッシブな機械語最適化（インライン展開やレジスタ割り当て）を施すことができます。
—
4. 陥りやすい文法エラーと注意点
初心者の開発者が `readonly` を使い始めるときによくハマるポイントをいくつかご紹介します。これさえ知っておけばバッチリです。
1. 途中で値を書き換えようとする（再代入エラー）
前述の通り、コンストラクタ以外での値の変更は一切できません。例えば、ビルダーパターンなどで後から値をセットするような設計とは相性が悪いです。値を変えたい場合は、新しいインスタンスを生成（コピー）しましょう。
2. ミュータブルなオブジェクトを `readonly` の中に突っ込む落とし穴
ここが最も重要です。`readonly` は「そのプロパティの参照（ポインタ）」が書き換わらないことを保証するものであり、指し示しているオブジェクトの中身までイミュータブルにするわけではありません。
class MutableData {
public int $value = 0;
}
class BadExample {
// readonlyであっても、内部の $data->value は書き換え可能！
public function __construct(
public readonly MutableData $data,
) {}
}
もし `MutableData` の中身が書き換わってしまうと、JITコンパイラは「安全に最適化できる」という前提を見失い、最適化の恩恵を十分に受けられなくなってしまいます。
真のパフォーマンスを引き出すためには、`readonly` と共に、指し示すオブジェクト自体も完全にイミュータブル（またはプリ型）で固めることが鉄則です。
—
まとめ
いかがでしたでしょうか？
Hackの `readonly` プロパティは、単なる「うっかりミスを防ぐための文法上のオモチャ」ではありません。その裏側では、HHVMのJITコンパイラがメモリバリアを削減し、CPUのパイプラインを最大限に効率化するための極めて高度な最適化ヒントとして機能しています。
型チェッカーのルールに従い、イミュータブルな世界観をコード全体に波及させることで、安全で保守性が高く、かつマシンパワーを極限まで引き出した爆速のHackアプリケーションを構築できるようになります。
ここをクリアできれば、あなたのHackコードはもう「ただ動くコード」ではなく、「アーキテクチャを理解し尽くしたプロのコード」です。
ぜひ、実際のプロジェクトでも積極的に `readonly` を取り入れて、この恩恵を体感してみてくださいね！