こんにちは！Hack言語の世界へようこそ。
他のプログラミング言語、例えばJavaやC#、あるいはTypeScriptあたりからやってきた開発者の多くが、Hackのコードを最初に見たときに「おや？」と首をかしげる瞬間があります。
それは何か？――「実行時に、型がどこにもない」ということです。
今回は、Hack言語の静的型システムと、それを裏で支えるHHVM（HipHop Virtual Machine）のJIT（Just-In-Time）コンパイラが、見えない型情報とどう向き合い、どうやって爆速な実行速度を生み出しているのか。その核心に迫る極限の知見を、分かりやすく紐解いていきましょう。
ここをクリアすれば、HackのRuntime（実行時）の挙動はバッチリマスターできますよ！
—
1. そもそも「型消去（Type Erasure）」とは何か？
Hackは非常に厳格な静的型付け言語です。コードを書くときは、次のようにガチガチに型を指定します。
namespace Hack\Samples;
class Greeter {
public function sayHello(string $name): string {
return “Hello, “.$name;
}
}
人間が見れば「`$name` は string でなければならない」と分かりますし、IDEやHackの型チェッカー（`hh_client`）も静的にこれを検証します。
しかし、ここで驚くべき事実があります。Hackのコンパイル結果（HHBC: HipHop Bytecode）において、この `string` という型情報は、基本的には「消去（Erased）」されます。
PHP（特にPHP 7以前や動的型付けの側面）の系譜を引くHackにとって、実行時（Runtime）のオブジェクトは、型による厳密なメモリレイアウトの固定化よりも、柔軟な動的表現を重視していました。実行時にすべての型情報をそのまま保持し続けると、メモリ消費量が増え、動的ディスパッチのオーバーヘッドも馬鹿になりません。
図解：型チェックからバイトコード生成への流れ
[ Hack ソースコード ]
public function sayHello(string $name): string
↓
[ 静的型チェッカー (hh_client) ] ← ここで型の整合性を完全保証！
↓
[ HHVM コンパイラ ]
- 型情報を「消去（Erasure）」または「最小限のメタデータ化」
- HHBC (バイトコード) へ変換
↓
[ JIT コンパイラ / 実行時 ]
「あれ？ じゃあ実行時に変な値が入ってきたらどうなるの？ 壊れちゃうの？」
ご安心ください。ここでHHVMのJITコンパイル構造と、賢い仕組みが活きてくるのです。
—
2. JITのジレンマ：型がないのに、どうやって最適化するのか？
現代の高速な仮想マシン（JavaのJVMやV8など）は、「型情報があるからこそ、マシン語へのアグレッシブな最適化（インライン展開やアンボックス化など）ができる」という性質を持っています。
もし実行時にすべてが「何でも入る箱（Variant型のようなもの）」だったらどうでしょう？ CPUは「いま入っているデータは整数か？それとも文字列か？」を毎回判定するガード処理（Type Check）を挟まなければならず、ネイティブコードの恩恵が台無しになります。
ここがJITの最大のジレンマです。
- Hackの言語仕様: 型はコンパイル時に消去される。
- JITの欲求: 高速化のために「いまこの変数は何型か」を常に知りたい。
このジレンマを解決するため、HHVMのJITは「プロファイリング実行と推論（Profile-Guided Optimization / Type Prediction）」というアプローチをとります。
—
3. HHVMの内部：JITはいかにして型を「視る」か
HHVMは、プログラムが実行されている最中（Runtime）に、コードの振る舞いをこっそり観察しています。これを専門用語でJITプロファイリングと呼びます。
例えば、先ほどの `sayHello` 関数が何度も呼び出されているとしましょう。HHVMのJITは、こう考えます。
> 「おっ、この `$name` に渡されている引数、99%の確率で `string` 型だな。よし、いまこの瞬間はこの変数が `string` であると仮定して、超高速なネイティブマシン語（x86-64等）にコンパイルしちゃおう！」
プロファイリングからJIT生成へのステップ
1. インタープリタ実行 / 翻訳の初期段階:
バイトコードを解釈しながら実行し、引数や戻り値の「実際の型」を監視（プロファイル）します。
2. ガード（Guard）付きJITコードの生成:
「もし `$name` が string なら、この最適化された超高速ルートを通る。もし違ったら（型違反や予期せぬ動的変更）、一度JITを脱出してインタープリタ（スロウパス）に戻る」というコードを生成します。
3. 型の特殊化（Type Specialization):
型消去によってソースコード上からは消えた型情報を、JITが「実行時の実績」に基づいて再構築し、最適化の武器として利用するのです。
この仕組みがあるおかげで、私たちは「書きやすくて安全な静的型付け」の恩恵を受けつつ、実行時には限界までチューニングされたネイティブスピードの恩恵を同時に受けることができます。
—
4. 初学者が陥りがちな「文法・設計上の罠」
この型消去とJITの挙動を知ると、Hack特有の「ハマりどころ」や「エラーの理由」がスッと理解できるようになります。
罠1: 「実行時型チェック（`is` 演算子など）」への過度な期待
他の言語から来た初心者がやりがちなのが、次のようなコードです。
namespace Hack\Samples;
class Box
public function checkType(mixed $val): void {
// ジェネリクス型 T の情報は実行時に消去されている！
// 実行時に T の具体的な型を直接判定することはできない
}
}
Hackでは、ジェネリクス（総称型）の型パラメーターも基本的には消去されます（Rethifiedな一部の例外を除き、Erasureが基本です）。そのため、実行時に「今渡されたのが `Box
【解決策】
型安全性の担保は、あくまでコンパイル時の `hh_client` に任せましょう。「実行時に動的な型を判定しまくるコード」を書くのではなく、「静的型システムがエラーを検知してくれる美しい設計」に寄せるのが、Hackをマスターする近道です。
—
まとめ：Hackの型は「未来への約束」
Hackの型システムとHHVMのJITの関係をまとめると、こうなります。
- 静的型（Hack Compiler）： 開発者とコンパイラの間で結ばれる「バグのないコードを書くための厳格な約束」。コンパイルが終われば、その役割の大部分は完了し、型情報は消去される。
- 動的プロファイル（HHVM JIT）： 消去された型情報を、実行時の観測によって「再発見」し、ハードウェアの限界を引き出すための最適化エンジン。
この絶妙なコンビネーションこそが、大規模なソーシャルプラットフォーム（Metaなど）のコードベースを支え続ける、HackとHHVMの真髄です。
「型が消えるのに、なぜ速くて安全なのか？」――その答えが分かれば、あなたのHackコーディングの視座は、もう一段階上のレベルに到達しています。
さあ、この強力なエンジンを相棒に、最高に洗練されたHackコードを書きに行きましょう！