【入門編】Hackのインターフェースと仮想メソッドテーブル（vtable）の最適化：動的ディスパッチを高速化する手法 – Hack言語コア・静的型システムとHHVMのアーキテクチャ解析バイブル

ようこそ、HackとHHVMの奥深い世界へ！

日頃からPHPやTypeScript、Javaなどを触っているみなさんにとって、「インターフェース（`interface`）」を使ったポリモーフィズム（多態性）はおなじみの設計パターンですよね。

interface Notifier {
public function send(string $message): void;
}

「インターフェースに依存させれば、コードが疎結合になって拡張性が上がる」——これはソフトウェア工学における大正義です。

しかし、一歩踏み込んで「CPUや実行エンジン（HHVM）の視点」からこれを見たとき、実は非常に重たい処理が裏側で動いていることをご存じでしょうか？

今回は、HackのコンパイルとHHVM（HipHop Virtual Machine）の心臓部であるJIT（Just-In-Time）コンパイラが、このインターフェース呼び出しをどのようにミリ秒・ナノ秒単位で超高速化しているのか、その立役者である「仮想メソッドテーブル（vtable）」と「インラインキャッシュ（Inline Cache）」の仕組みを、優しく解剖していきます！

ここを理解できれば、単に「動くコードが書ける」だけでなく、「処理系に愛される超高速なHackコード」が書けるようになりますよ。リラックスしてついてきてくださいね。

—

1. まずは基本から：Hackのインターフェース呼び出し

まずは、よくある通知システムを題材にしたHackのコードを見てみましょう。

namespace MyFastApp;

interface Notifier {
public function send(string $message): void;
}

final class EmailNotifier implements Notifier {
public function send(string $message): void {
// メール送信処理
echo “Sending Email: {$message}\n”;
}
}

final class SlackNotifier implements Notifier {
public function send(string $message): void {
// Slack通知処理
echo “Sending Slack: {$message}\n”;
}
}

// 呼び出し側の関数
function broadcast(Notifier $notifier, string $msg): void {
// ここに注目！
$notifier->send($msg);
}

なぜこれが「CPUにとって面倒」なのか？

静的関数（`MyClass::staticMethod()`）や、継承のない具体的なクラスへの直接呼び出しであれば、コンパイラは「メモリの番地 `0x7fff1234` にある関数へジャンプせよ」という直球の命令（ダイレクトコール）を出せます。

しかし、`broadcast(Notifier $notifier, …)` の場合、実行時になるまで `$notifier` の中身が `EmailNotifier` なのか `SlackNotifier` なのか決まりません。

そのため、CPUは毎回「君、どのクラス？」「そのクラスの `send` メソッドはメモリのどこにあるの？」と探偵のように調べ回る必要があります。これを動的ディスパッチ（Dynamic Dispatch）と呼びます。

—

2. メモリの裏側：vtable（仮想関数テーブル）ルックアップ

この「探偵の調査」を支える古典的な仕組みが vtable（Virtual Method Table / 仮想関数テーブル） です。

HHVMの内部では、オブジェクトは単なるデータの塊ですが、その先頭には必ず「どのクラスなのか」を示すメタデータ（Classメタオブジェクト）へのポインタが存在します。

オブジェクトとvtableのメモリ構造

通常の動的ディスパッチでは、インターフェース経由のメソッド呼び出しを行うたびに以下のステップを踏みます。

1. オブジェクトのメモリを見る
2. ヘッダからクラス情報をたどる
3. クラス情報の中にある vtable（関数の住所録） を開く
4. 「`send` メソッド」に割り当てられたスロット（例えばインデックス1）のアドレスを読み出す
5. そのアドレスへジャンプする（間接ジャンプ：Indirect Call）

何が問題なのか？

現代のCPUは、パイプライン処理といって「先の命令を予測してどんどん先読み実行」することで圧倒的なスピードを出しています（分岐予測）。

しかし、上記のような「ポインタを2回も3回もたどって、行き先が毎回変わるかもしれないジャンプ」は、CPUの分岐予測を狂わせ、パイプラインを停止（ストール）させる最大の原因になります。メモリの参照待ち（キャッシュミス）も発生し、劇的に遅くなってしまうのです。

—

3. HHVM JITの切り札：「インラインキャッシュ（Inline Cache）」

「じゃあ、オブジェクト指向を使うとパフォーマンスは諦めるしかないの？」

いいえ、そんなことはありません。ここで登場するのが、HHVMの真骨頂である JITコンパイラ と インラインキャッシュ（Inline Cache: IC） です。

JITの観察眼：「いつも同じヤツが来てないか？」

ソフトウェアの実行パターンを統計的に見ると、ある場所の `$notifier->send()` に渡されるオブジェクトは、「実は99%の確率で毎回 `EmailNotifier` だった」というケースが圧倒的多数を占めます（これを「局所性」と呼びます）。

HHVMのJITは、実行中にそのコードがどう呼ばれているかをプロファイリングし、呼び出し箇所の機械語をその場で書き換えます。

キャッシュの進化ステップ

① 未初期化状態（Uninitialized）

最初はまだ誰も通っていません。通常の低速なvtable検索を行います。

② モノモーフィック（Monomorphic: 単一型）状態 ★最速！

「おや？ここを通るのは毎回 `EmailNotifier` だな」とJITが検知すると、呼び出し箇所の機械語を以下のような超単純なアセンブリ命令相当に書き換えます。

// JITが生成するネイティブコードのイメージ（擬似コード）
if ($notifier->class_id === EmailNotifier::CLASS_ID) {
// vtableを見ずに、関数の絶対番地へダイレクトジャンプ！
EmailNotifier::send($notifier, $msg);
} else {
// 違うクラスが来たら、低速フォールバック（再検索）へ
slow_vtable_lookup($notifier, ‘send’, $msg);
}

この比較命令（`cmp` と `je`）は、CPUにとって朝飯前です。
vtableのポインタを何度もたどる必要がなくなり、分岐予測もほぼ100%的中するため、直接関数を呼ぶのとほぼ同等の極限スピードが手に入ります。

③ ポリモーフィック（Polymorphic: 複数型）状態

「たまに `SlackNotifier` も来るようになったぞ」となると、JITはインラインキャッシュを拡張し、数スロット（2〜4個程度）の条件分岐チェーンを作ります。

// 擬似コード
if ($notifier->class_id === EmailNotifier::CLASS_ID) {
EmailNotifier::send(…);
} else if ($notifier->class_id === SlackNotifier::CLASS_ID) {
SlackNotifier::send(…);
} else {
slow_vtable_lookup(…);
}

数個程度であれば、テーブル検索よりこの「条件付き直接呼び出し」のほうが圧倒的に高速です。

④ メガモーフィック（Megamorphic: 多数型）状態

5種類も10種類もの異なるクラスが次々と代わる代わるやってくると、もはやインラインキャッシュの限界を超えます。
JITは「諦めて」汎用のグローバルキャッシュや、ハッシュテーブルベースの動的ルックアップに戻します。

—

4. 初心者がハマりがちな落とし穴：メガモーフィックの罠

ここで、Hackを学び始めた方がやってしまいがちなパフォーマンスアンチパターンを紹介します。

やってしまいがちなコード

何十種類もの異なるイベントハンドラやプラグインを、ひとつの巨大なループで同じインターフェースを通じて呼び出すケースです。

namespace MyFastApp;

interface Worker {
public function execute(): void;
}

function processJobs(vec $workers): void {
// $workers の中に、20種類の異なるクラスのインスタンスが
// ランダムな順序で詰め込まれていると…
foreach ($workers as $worker) {
// 警報！JITのインラインキャッシュがパンクする！
// (メガモーフィック・スラッシングの発生)
$worker->execute();
}
}

何が起きるのか？

ループが回るたびに `$worker` の型が `TypeA` -> `TypeB` -> `TypeC` -> `TypeD`… と目まぐるしく変化します。
すると、せっかくJITが最適化しようとしたインラインキャッシュが吹き飛び、メガモーフィック状態へ転落します。

毎周回、CPUの分岐予測ミスとメモリルックアップが頻発し、処理速度が数倍〜十数倍も低下することがあるのです。

どう書くのが美しい先輩のアプローチか？

もしバッチ処理などで大量のデータを扱うなら、「同じ型のものはまとめて処理する」、あるいは静的型をできるだけ具体的に保つのが鉄則です。

// クラスごとにグルーピングして処理するイメージ
function processBatchedJobs(
vec $emailWorkers,
vec $slackWorkers,
): void {
// このループの中は 100% EmailWorker しか来ない！
// => JITはモノモーフィックとしてインライン展開（Inlining）まで攻め込める！
foreach ($emailWorkers as $w) {
$w->execute();
}

// こちらも 100% SlackWorker のみ
foreach ($slackWorkers as $w) {
$w->execute();
}
}

「型を分けるだけでそんなに変わるの？」と思うかもしれませんが、HHVMのJITは、型が1種類だと確信できた瞬間、メソッド呼び出し自体を消し去って中身をその場に展開するインライン展開（Inlining）という最高峰の最適化を発動させます。

—

まとめ：型システムの美しさは、速度の美しさ

インターフェースとvtable、そしてJITのインラインキャッシュについて、イメージが掴めましたでしょうか？

今回のポイントをギュッと凝縮しておさらいしましょう。

1. インターフェース経由の呼び出しは、本来vtableを経由するためCPUには重い負荷がかかる。
2. HHVMのJITコンパイラは「インラインキャッシュ（IC）」を使い、実行時に動的ディスパッチをダイレクトジャンプへ書き換えている。
3. 呼び出し箇所に来るクラスが1〜2種類（モノモーフィック）であれば、極限のネイティブスピードが出る。
4. 型がランダムに入り乱れる「メガモーフィック」な呼び出しを避ける設計が、ハイパフォーマンスHackコードの秘訣。

Hackの型システムは、単にプログラマのバグを防ぐためだけにあるのではありません。
厳格な型情報があるからこそ、裏側でHHVMのJITコンパイラが「迷いなく」コードを極限まで最適化できるのです。

「抽象化の美しさを保ちながら、裏側のJITに優しく書く」
この感覚が掴めれば、あなたも立派なHackエンジニアです。自信を持って、クリーンで高速なHackの世界を楽しんでくださいね！