こんにちは。Hackの深淵へようこそ。
HHVMのコードベースを日々眺めていると、「なぜHackはこれほどまでにWebのトラフィックを捌き切れるのか」という問いの答えが、コンパイラの最適化の端々に隠されていることに気づきます。
今日は、その中でも特に「メモリの魔術」とも呼べる、JITコンパイルにおける「脱出解析（Escape Analysis）」についてお話ししましょう。
—
1. なぜ「ヒープ」は遅いのか？
通常、私たちが `new` を使ってオブジェクトを生成するとき、その実体はヒープ（Heap）という広大なメモリ領域に配置されます。ヒープは寿命が予測できないオブジェクトを管理するのに便利ですが、大きな代償を払っています。
1. メモリ確保のオーバーヘッド: どこに空きがあるかを探す計算コスト。
2. キャッシュの不整合: ヒープはメモリ全体に散らばるため、CPUキャッシュが効きにくい。
3. GC（ガベージコレクション）の負担: 「もう使われていないか？」を監視し、回収するサイクルが走るたびにCPUを消費する。
もし、あるオブジェクトが「特定の関数のスコープ内でしか使われない」ことがコンパイラに証明できたらどうなるでしょうか？ そう、ヒープに置く必要なんてないのです。
—
2. 脱出解析：オブジェクトの「逃走」を阻む
ここで登場するのが脱出解析（Escape Analysis）です。
HHVMのJITコンパイラは、コードを機械語に変換する直前に、オブジェクトが関数の外へ「脱出（Escape）」するかどうかを徹底的に監視します。
- 脱出しない: その関数の実行が終われば役目を終える。 → スタック領域に割り当てよう！
- 脱出する: リターン値になったり、クラスのプロパティに代入されたりする。 → 仕方ない、ヒープに置こう。
図解：メモリ配置のイメージ
[スタック領域] : 高速・自動解放（関数の終わりで消える）
+————–+
| オブジェクトA | <-- 脱出しないと判定！ここに配置！
+--------------+
[ヒープ領域] : 低速・GC監視対象
+--------------+
| オブジェクトB | <-- 他の場所からも参照される…ここに配置
+--------------+
スタック割り当てができれば、メモリ確保は「スタックポインタをずらすだけ（数ナノ秒）」で済み、GCの監視対象から外れるため、パフォーマンスは劇的に向上します。
---
3. 実践：Hackでの「スタックに優しい」書き方
では、どのようなコードが脱出解析の恩恵を受けやすいのでしょうか。
<<__EntryPoint>>
function main(): void {
// このPointオブジェクトは、この関数内だけで消費される
// コンパイラは「この関数から出ない」と判断し、
// ヒープではなくスタックに割り当てようと試みる
$p = new Point(10, 20);
echo $p->getX() + $p->getY();
}
class Point {
public function __construct(private int $x, private int $y) {}
public function getX(): int { return $this->x; }
public function getY(): int { return $this->y; }
}
陥りやすい罠：なぜ最適化が効かないのか？
脱出解析を阻害する「NGコード」も知っておきましょう。
function bad_example(): Point {
$p = new Point(1, 2);
return $p; // ヒープ行き確定！
// 戻り値として関数外に「脱出」しているため、
// スタックに置くと関数終了時にメモリが消滅し、バグになるからですね。
}
また、以下のようなコードも解析を複雑にします。
- グローバル変数への代入: `$GLOBALS[‘p’] = new Point();`
- 例外スロー: `throw new Exception();` （例外発生時のスタックトレース生成のために保持が必要）
- クロージャへのキャプチャ: `use ($p)` でクロージャに持ち込む。
—
4. 現場のアーキテクトからのアドバイス
Hackを扱う上で意識してほしいのは、「小さく完結するスコープ」です。
オブジェクトを巨大なコンテナのように使い回すのではなく、必要な時に生成し、その場ですぐに使い切るような設計を心がけてください。そうすれば、HHVMのJITコンパイラは驚くほど賢く、あなたのコードをメモリ効率の極限へと導いてくれます。
「静的型システム」があるおかげで、HHVMは型情報からオブジェクトのサイズや性質を正確に把握できます。これは他の動的言語には真似できない、Hackだけの強力な武器です。
この仕組みを理解しているだけで、単なるコーダーから、パフォーマンスを自在に操る「システムエンジニア」へと一歩近づけたはずですよ。
ここをクリアすれば、もうHackのメモリ管理の入り口はバッチリです。次はぜひ、HHVMのプロファイラを使って、実際に最適化が効いているか確認してみてください。エンジニアとしての視界が、また一つ開けるはずです。