やあ。Hack言語の世界へようこそ。
君が今、HHVMの深淵――つまり、コードが単なる文字列から「CPUが直接解釈する力」へと変わる場所――に興味を持ってくれたことを嬉しく思う。
今日は、Hackを使いこなす上で避けては通れない、しかし多くのエンジニアが「魔法」だと思って見過ごしている「JIT（Just-In-Time）コンパイルによるインライン化」の話をしよう。
ここを理解すれば、君の書くコードは単なる命令の羅列ではなく、HHVMという巨大なエンジンを最大限に加速させる「最適化された設計図」に変わるはずだ。
—
1. なぜ「関数呼び出し」はコストがかかるのか？
まず、CPUの視点に立ってみよう。関数が呼ばれるたびに、プログラムはこんな面倒なことを裏側でやっている。
1. スタックフレームの作成: 引数や戻り先のアドレスをメモリに積む。
2. ジャンプ: 別のコード領域へ実行位置を飛ばす。
3. コンテキストスイッチ: レジスタの状態を一時退避させる。
4. 復帰: 終わったらまた元の場所に戻る。
小さな関数をループの中で数百万回呼び出すと、この「準備と片付け」だけでCPUの貴重なサイクルが湯水のように消えていく。これを防ぐのが「インライン展開（Inlining）」だ。
2. HHVMのJITが見ている「閾値」という名の境界線
HHVMは賢い。実行中に「この関数、何回も呼ばれてるな。わざわざジャンプしなくても、コードそのものをその場に埋め込んだ方が速くね？」と判断する。これがインライン化のヒューリスティックだ。
しかし、無制限にインライン化すればコードサイズが爆発し、CPUの命令キャッシュ（L1/L2 Cache）が溢れて逆に遅くなる。だからこそ、HHVMには「インライン化の閾値」があるんだ。
- 関数のサイズ（バイトコードの量）: 長すぎる関数はインライン化されない。
- 呼び出し頻度: プロファイル結果に基づき、ホットな関数だけが優先される。
- 再帰の深さ: 無限ループを防ぐため、一定以上の再帰はインライン化しない。
3. コードで見る「インライン化を誘発する」設計術
インライン化を最大限に活用するための、現場の知恵を教えよう。
悪い例：抽象化しすぎた「小さな関数」の乱立
// 何でもかんでも切り出しすぎると、JITが迷う原因になる
function get_data_value(int $a): int {
return $a 2;
}
for ($i = 0; $i < 1000000; $i++) { $val = get_data_value($i); // 頻繁なジャンプが発生 }
良い例：ホットパスを意識した設計
もしこれがループの内部なら、HHVMに「これは単純な操作だ」と認識させる必要がある。
// 型が明確で、ロジックが単純な関数はインライン化されやすい
<<__AlwaysInline>> // 明示的なヒントを与えることも可能
function fast_math(int $a): int {
return $a << 1; // ビット演算は非常に高速
}
for ($i = 0; $i < 1000000; $i++) {
// コンパイラが「ここにコードを直接置いたほうが速い」と判断しやすくなる
$val = fast_math($i);
}
4. 陥りやすい罠：型が曖昧だとJITは死ぬ
Hackの静的型システムは、単なる「エラーチェック」じゃない。JITコンパイラへの最強のヒントなんだ。
もし引数の型が `mixed` だったり、型推論が効かないコードを書いてしまうと、HHVMは「あ、これ引数の型を確認するコード（Guard）を毎回入れなきゃ…」と判断する。インライン化の前に「型確認」というオーバーヘッドが差し込まれ、最適化のチャンスが消滅するんだ。
極意： `type alias` や `shape` を駆使し、関数に渡されるデータの形をHHVMに対して完全に透明化しなさい。型が確定しているコードこそが、JITのインライン化の恩恵をフルに受ける。
—
まとめ：君が明日から意識すべきこと
1. 「ホットなループ」には小さな関数を置く: ただし、ロジックは単純に保つこと。
2. 型を厳格に定義する: HHVMが型チェックの命令を省略できるように手助けする。
3. 過度な抽象化を避ける: 読みやすさは大事だが、パフォーマンスが求められる部分では「物理的なコードの距離」を意識する。
Hackの静的型システムは、君とHHVMの「契約」だ。君が型で約束を守れば、HHVMは君のコードをマシン語の極限まで加速させてくれる。
ここをクリアした君なら、もうHHVMの内部動作を恐れることはない。次は、プロファイラを見ながら「どこがインライン化されていないか」を追跡する冒険に出かけよう。
何か分からないことがあれば、いつでも聞きに来てくれ。エンジニア同士、深い話ができるのを楽しみにしているよ。