こんにちは！Hackの世界へようこそ。
PHPの使いやすさを引き継ぎながら、Facebook（Meta）の超巨大なトラフィックを支えるために進化した言語、それがHackです。
Hackを学び始めたばかりのあなたは、「型をしっかり書くとエラーが防げて便利だな」と感じているかもしれません。しかし、Hackの本質的な凄さはそれだけではありません。あなたの書いた「型」は、Hackを動かす超高速エンジン「HHVM（HipHop Virtual Machine）」にダイレクトに伝わり、マシンパワーを限界まで引き出すための「究極のスパイス」として使われているのです。
今日は、HHVMの心臓部で行われている「投機的最適化（Speculative Optimization）」という魔法と、それが解けて動きが遅くなってしまう「デオプティマイゼーション（最適化の取り消し：Deoptimization）」のドラマについてお話しします。
「どう書けば、HHVMが最もハッピーに、爆速で動いてくれるのか？」
その秘密を、エンジニアの先輩として、どこよりも分かりやすく、かつ深掘りして伝授しますね。ここをクリアすれば、Hackの基本とHHVMのアーキテクチャはバッチリマスターできますよ！
—
1. HHVMのJITコンパイラと「投機的（予測）最適化」の仕組み
まず、HHVMがどうやってプログラムを実行しているのか、イメージ図を交えて見ていきましょう。
HHVMの中には、JIT（Just-In-Time）コンパイラという、コードを実行しながら「もっと速く走れる機械語（マシンコード）」をその場で組み立てる超優秀な職人が住んでいます。
[あなたのHackコード]
│
▼ (コンパイル)
[HHBC（中間バイコード）]
│
▼ (HHVM JITが監視・実行)
┌────────────────────────────────────────┐
│ 「うーん、この関数、何回も呼ばれるな」 │
│ 「引数は毎回『int型（整数）』だな！」 │
│ 「よし！ int専用の爆速マシンコードを作ろう！」│
└────────────────────────────────────────┘
│ （投機的最適化！）
▼
[超高速な機械語（Translation Cacheに保存）]
JITコンパイラは、プログラムが動いている様子（プロファイル情報）をじっと観察しています。そして、「この関数に渡されるデータは、きっと次も `int`（整数）に違いない！」と投機（予測）して、その型に特化した無駄のない超高速な機械語を作り出します。これを「投機的最適化」と呼びます。
予測を支える「型ガード（Type Guard）」
ただし、予測は外れることもあります。そのため、JITが作った高速コードの入り口には、必ず「型ガード（Type Guard）」という高速な検問所が設置されます。
「おい、お前は本当に `int` か？」と一瞬でチェックし、合致していればそのまま高速道路（JITコード）をノーブレーキで駆け抜けます。これが、HackがPHPとは次元の違うスピードで動く最大の理由です。
—
2. 予測が外れたときの悲劇：「デオプティマイゼーション（Deopt）」
しかし、もし型ガードの検問で「いえ、私は `string`（文字列）です」とか「`null` です」というデータがやってきたらどうなるでしょう？
予測は大外れです。そのまま進むとプログラムがクラッシュしてしまうため、HHVMは急ブレーキをかけます。
【型ガード検問所】
「おい、intじゃない奴が来たぞ！ 緊急事態発生！」
│
▼ (JITロードから強制脱出 = Side Exit)
[レジスタやスタックの状態を、安全な古い状態へ巻き戻す]
│ (非常に重い処理！)
▼
[低速な汎用コード（またはインタープリタ）で実行し直す]
この「予測が外れて、せっかく作った高速コードを破棄し、安全な低速モード（インタープリタなど）へ戻る処理」のことを「デオプティマイゼーション（Deoptimization：通称 Deopt / デオプト）」、そして高速道路から一般道へ脱出することを「サイドエグジット（Side Exit）」と呼びます。
Deoptが発生すると、CPUのキャッシュは乱れ、レジスタの再マッピングなどの超重い復旧処理が裏で走るため、プログラムの実行速度は一気にガタ落ちしてしまいます。
つまり、「HHVMを速く動かす＝Deoptを発生させない（型ガードを常に一発パスさせる）」ということなのです！
—
3. Deoptを引き起こす「やってしまいがちなアンチパターン」
では、どんなコードを書くとDeoptが発生しやすくなるのでしょうか？ 具体的な例を見てみましょう。
アンチパターン1：型がコロコロ変わる「カメレオン変数」
他の動的型付け言語から来た開発者が、ついやってしまいがちなのがこれです。
// ⚠️ Deoptを引き起こしやすいコード
function process_data(mixed $input): void {
// $input の型が実行時まで全くわからない！
if (is_int($input)) {
// $input は int として処理
$result = $input + 10;
} else if (is_string($input)) {
// $input は string として処理
$result = strlen($input);
}
}
なぜダメなのか？
HHVMのJITから見ると、`$input` が `int` なのか `string` なのか予測できません。
1回目に `int` が来たら「`int` 専用コード」を作りますが、2回目に `string` が来ると型ガードに引っかかってDeopt（Side Exit）が発生します。そしてJITは「ちぇっ、もう予測するのをやめて、遅い汎用コードで動かそう…」と諦めてしまうのです。
アンチパターン2：いたる所に潜む `null`（Nullable型の乱用）
// ⚠️ Nullable（?型）を安易に使いすぎるコード
function get_discount(?int $price): int {
if ($price === null) {
return 0; // nullの時のフォールバック
}
return (int)($price 0.9);
}
なぜダメなのか？
`?int`（Nullable int）は、一見安全に見えますが、JITにとっては「`int` か `null` のどちらが来るか常にビクビクしなければいけない」状態です。特に、ループの中でたまに `null` が混ざるようなデータ構造だと、その都度型ガードの判定が走り、分岐予測の失敗とDeoptの温床になります。
—
4. HHVMを味方につける！Deoptを避けるための「黄金の書き方」
それでは、HHVMのJIT職人が泣いて喜ぶ、爆速かつ安全なHackコードの書き方をマスターしましょう！
対策1：型は「極限まで具体的に」固定する
JITに「余計な心配」をさせないために、型は可能な限り狭く、具体的に指定します。
// 💖 JITが最も喜ぶ、型が完全に固定されたコード
function calculate_tax(int $price): int {
// 引数は絶対 int、戻り値も絶対 int！
// JITは「型ガード」すら省略した究極の機械語を生成できます（Devirtualization）
return (int)($price 0.1);
}
対策2：`null` は入り口でシャットアウトする（早期リターン）
どうしても `null` が入る可能性がある場合は、関数の奥深くやループの中でダラダラと `null` を引きずり回さず、一番最初の「門番」でシャットアウトします。
// 💖 早期リターンで型を確定させるスマートなコード
function process_user_score(?int $score): void {
// 1. まず最初に null を排除する！
if ($score === null) {
return;
}
// 2. ここから下では、JITは「$score は 100% int だ」と確信して、
// 一切の型ガードなしで高速処理できます！
$bonus = $score + 100;
echo “Your bonus is: {$bonus}\n”;
}
対策3：クラスは `final` にして多態性（ポリモーフィズム）の爆発を防ぐ
JITは、メソッドが呼び出されたときに「どのクラスのメソッドを呼べばいいか」を予測します。クラスが継承されまくっていると、JITは迷ってしまいます。
// 💖 classに final をつける
final class PaymentProcessor {
public function pay(int $amount): void {
// 処理
}
}
// 呼び出し側
function checkout(PaymentProcessor $processor, int $amount): void {
// $processor は final なので、これ以上子クラスが存在しません。
// JITは「どのメソッドを呼ぶべきか」を100%断定できるため、
// 呼び出しのオーバーヘッドをゼロにする「インライン化（Inlining）」を行います！
$processor->pay($amount);
}
`final` キーワードをつけるだけで、Hackチェッカーが静的解析で安全を保証してくれるだけでなく、HHVMがメソッド呼び出しを極限まで高速化（脱仮想化：Devirtualization）してくれるのです。
—
5. まとめ：Hackの静的型システムは、HHVMの「ブースター」
ここまでの内容をギュッと整理しましょう！
| やってしまいがちな書き方 (Deoptの原因) | HHVMを爆速にする書き方 (JITの好物) |
| :— | :— |
| `mixed` や `any` を使った曖昧な型定義 | `int`, `string` などの具体的な一意の型 |
| 関数の途中で何度も `is_null()` をチェックする | 関数の先頭で早期リターンして型を確定させる |
| どこまでも継承可能なオープンなクラス | `final` クラスにして継承の可能性を閉じる |
他の言語では、「型」は開発者がバグを起こさないための「命綱」としての役割が主です。
しかしHackにおいては、「型は、HHVMというモンスターマシンを限界突破させるためのニトロ（燃料）」なのです。
あなたが厳格に、美しく型を書けば書くほど、HHVMのJITコンパイラは「型ガード」の検問を取り払い、Deopt（最適化の失敗）というブレーキを踏むことなく、光の速さでコードを実行してくれます。
「このコード、JITは喜んでくれるかな？」
そんな視点を持ってHackのコードが書けるようになれば、あなたはもう初心者ではありません。HHVMのポテンシャルを100%引き出す、一流のHackアーキテクトへの第一歩を踏み出していますよ！
この調子で、楽しみながら美しいHackコードを書いていきましょう！応援しています！