みなさん、こんにちは！Hackの世界へようこそ。
今日も元気にコードを書いていますか？
PHPの扱いやすさと静的型システムの安全性を完璧なバランスで融合させた言語、それがHackです。そして、その裏で圧倒的な実行スピードを叩き出している心臓部がHHVM（HipHop Virtual Machine）です。
Hackを使い始めたばかりの皆さんから、よくこんな疑問を聞かれます。
> 「Hackって型チェック（HH_CLIENT）で厳格に型を検査しているのに、なぜ実行時（HHVM）でも型のチェックが必要なんですか？」
> 「JITコンパイラって、実行中に型が変わったらどうやって追従しているの？」
素晴らしい着眼点です！
実は、HHVMが世界最高峰のパフォーマンスを誇る秘密は、まさにこの「JITにおける型ガード（Type Guard）の動的再評価」という極めて洗練された仕組みにあるのです。
今日は、HHVMの内部で何が起きているのかを、イメージしやすい図解的な解説とともに、噛み砕いて紐解いていきましょう。ここをクリアすれば、Hackのパフォーマンスを最大限に引き出すコードが書けるようになり、基本はバッチリマスターできますよ！
—
1. そもそも「型ガード（Type Guard）」ってなに？
まずは概念から捉えていきましょう。
Hackのソースコードは、HHVMによって一度HHBC（HHVM Bytecode）という中間命令に変換され、実行時にJIT（Just-In-Time）コンパイラがPC（CPU）が直接理解できるネイティブマシンコード（x86-64やAArch64の命令）に変換します。
もし、変数の型が「絶対に `int` である」と分かっていれば、JITは無駄な型チェックをすべて省いた爆速のマシンコード（単なる `add` 命令など）を生成できます。
しかし、PHPからの過渡期コードや `mixed` 型、Nullableな型（`?int`）など、「実行してみるまで型が100%確定しないコード」も存在しますよね。
そこでJITコンパイラは、ネイティブコードの先頭に「型ガード（Type Guard）」という小さなチェック機構を埋め込みます。
［イメージ図］関所を守る「型ガードの兵士」
[呼び出し元] ──(値を受け渡す)──> [ JIT生成ネイティブコード ]
│
▼
┌────────────────────┐
│ 【型ガードの関所】 │
│ 「お前は本当にintか?」 │
└─────────┬──────────┘
│
┌─────────────┴─────────────┐
▼ ▼
【 YES 】 【 NO 】
(そのまま超高速処理へ) (Side-exit：横道へ退避!)
型ガードとは、いわば「このネイティブコードに入れるのは、特定型データだけだ！」と検査する関所の兵士のような存在です。
—
2. 実行時に型が変わると何が起きる？（実際のコードで見る）
では、具体的なHackコードを見てみましょう。
例えば、次のように `mixed` 型（どんな型でも受け取れる型）を受け取る関数があるとします。
<<__EntryPoint>>
function main(): void {
// 1回目：整数(int)を渡す
process_value(42);
// 2回目：文字列(string)を渡す（実行時の型変化！）
process_value(“Hello, Hack!”);
}
function process_value(mixed $val): void {
// mixed型なので、実行時まで具体的な型がわからない
if ($val is int) {
// 整数処理
$result = $val + 10;
echo “Int result: {$result}\n”;
} else if ($val is string) {
// 文字列処理
echo “String result: {$val}\n”;
}
}
このコードを実行するとき、HHVM内部では以下のような「ドラマ」が繰り広げられています。
ステップ1：初回実行（`$val` が `int` のとき）
1. JITコンパイラは `process_value` が呼び出された際、実引数が `int` であることを察知します。
2. 「`$val` が `int` であること」を前提としたネイティブコード（Tracelet） を生成します。
3. コードの先頭には `Guard: $val is int` という型ガードを設置します。
この時点では、`$val` が `int` であれば超高速に実行されます。
—
3. 型が変化した瞬間のマジック：「Side-exit」と「動的再評価」
問題はここからです。2回目の呼び出しで `process_value(“Hello, Hack!”)` と、`string` 型が渡されました。
設置された型ガード（関所）は「お前は `int` じゃないな！」と検知し、型ガードのチェックが失敗（Guard Fail）します。
「えっ、クラッシュしちゃうの？」と心配になりますよね。大丈夫です。ここからHHVMの真骨頂である「Side-exit（側方退避）」と「動的再評価（Re-translation）」が動きます！
［図解］Side-exit（側方退避）から再コンパイルへの流れ
1. 型ガード失敗 (Guard Fail!)
│
▼
2. Side-exit (側方退避)
│ ── Native領域から Interpreter(インタプリタ)領域へ脱出
▼
3. インタプリタで安全に続きを実行しつつ、新しい型(string)をプロファイリング
│
▼
4. JITが「多態的(Polymorphic)な型領域」としてネイティブコードを再生成！
│
▼
5. 次回以降は int も string もガードを通過して爆速実行！
仕組みの解説：
1. Side-exit（側方退避）:
型ガードが破れると、JITコードの実行を安全に中断し、CPUのレジスタ状態をHHVMのVMスタックに書き戻して、一時的にインタプリタ（遅いが安全な低速実行モード）へ退避します。
2. 型情報のフィードバック:
インタプリタで実行しながら、「あ、この関数には `string` も入ってくるんだな」という新しいプロファイリング情報を収集します。
3. Traceletの動的再コンパイル（Re-translation）:
JITコンパイラは、`int` 用と `string` 用の両方に対応できる、あるいは `string` 専用の新しいネイティブコード分岐（Poly-morphic Tracelet）を裏で動的に再生成・更新します。
これにより、次回以降の呼び出しでは、どちらの型が来ても高速に処理できるようになるのです！
—
4. 初心者が陥りやすい罠：「JITスラッシング（再コンパイルの嵐）」
この仕組みは非常に賢いですが、「JITに頼りすぎる」とパフォーマンスが低下するアンチパターンが存在します。
それが、ひとつの変数に無秩序にコロコロと異なる型を代入するコードです。
❌ 陥りやすいアンチパターンコード
function bad_example(bool $flag): void {
// 変数 $data の型が条件によって激しく変化する
$data = null;
if ($flag) {
$data = 100; // int に変化！
} else {
$data = “Unassigned”; // string に変化！
}
// 型が安定しないまま大量のループ処理に突入
for ($i = 0; $i < 10000; $i++) {
// 実行のたびに型ガードの破壊とSide-exitが多発する危険性！
process_data($data);
}
}
なぜこれがダメなのか？
型がコロコロ変わりすぎると、JITコンパイラは「型ガードの失敗 ➔ Side-exit ➔ 再コンパイル ➔ また型ガード失敗…」を繰り返してしまいます。これをJITスラッシング（JIT Thrashing）と呼びます。
JITコンパイル自体にもCPUのメモリと計算コストがかかるため、これが発生するとせっかくのHHVMの爆速性能が台無しになってしまうのです。
—
5. Hackらしくスマートに書くためのベストプラクティス
では、どう書けばHHVMのJITエンジンを最大限に喜ばせることができるでしょうか？答えはシンプルです。「型を明確にし、型揺れを防ぐ」ことです！
⭕ 改善されたプロのコード
// 1. 可能な限り Strict Mode (strict型定義) で書く
// 2. 複数の型を持つ可能性があるなら Shape や Nullable、または Enum を活用する
enum Status: string {
PENDING = ‘pending’;
ACTIVE = ‘active’;
}
// 戻り値の型や引数の型を明確に指定する
function process_data_smart(?int $data): int {
// Nullableの型絞り込み（Type Refinement）
if ($data === null) {
return 0;
}
// ここに到達した時点で、HHVMも静的型チェッカーも「100% int」だと確信できる！
// 型ガードは不要（または最速のガード1回だけ）になり、爆速のマシンコードが走る！
return $data 2;
}
先輩からのポイントアドバイス 💡
- 型絞り込み（Type Refinement）を活用しよう
`if ($val is int)` のように型を早めにチェックして分岐させると、HHVMのJITはその `if` ブロックの中を「完全な `int` 専用コード」として最適化できます。
- `mixed` は最小限に
どうしても必要な場所以外では `mixed` の使用を避け、具体型（`int`, `string`, `Vector
—
まとめ：型システムとJITのタッグで最強のHackライフを！
HHVMにおける型ガードの動的再評価の仕組み、いかがでしたでしょうか？
最後に今回の重要なポイントを振り返りましょう！
1. 型ガード（Type Guard）は、JIT生成コードの先頭で「想定通りの型か」を検査する関所。
2. 型が変わるとSide-exit（側方退避）が発生し、安全にインタプリタへ退避する。
3. HHVMは実行時の型変化を学習し、ネイティブコードを動的に再コンパイル（Re-translation）して追従する。
4. 型ヒントをしっかり書くことで、型ガードのオーバーヘッドをゼロにし、HHVMの真の爆速性能を引き出せる！
Hackの厳格な「静的型システム」と、HHVMの賢い「動的JITアーキテクチャ」は、互いに支え合う最強のパートナーです。
型をしっかり意識してコードを書くだけで、HHVMはあなたのコードを世界最高峰のスピードへと導いてくれます。ここを理解できれば、もうHackの基礎はバッチリマスターですよ！
次回は、HHVMのメモリ領域（Heap/Local）とガベージコレクションのディープな世界についてお話ししましょう。楽しみに待っていてくださいね！