HHVMのJITとCPUキャッシュの親和性：Hackデータ構造設計の極限最適化
HHVM（HipHop Virtual Machine）のアーキテクチャ、そしてHack言語の厳格な静的型システムを極限まで使い倒す者にとって、パフォーマンスのボトルネックはもはや「PHP的な動的処理」そのものではない。問題は、JIT（Just-In-Time）コンパイラが生成したネイティブコードがいかにCPUのハードウェア特性、特にキャッシュ階層（L1i/L1d/L2/L3）とTLB（Translation Lookaside Buffer）に適合しているかだ。
本稿では、HHVMのTC（Translation Cache）構造と、CPUキャッシュの物理的特性を直結させ、Hackのデータ構造設計がいかに実行時のクロックサイクルを支配するかを、ランタイムの深淵から解説する。
—
1. HHVM JITの内部構造とコード・データの分離
HHVMは、バイトコードを一度プロファイリング付きインタープリター（HNi / Region Assembler）で実行し、ホットスポットを検知してマシン語へコンパイルする。この際、生成されるコードと、それらが操作するオブジェクトのメモリレイアウトには、CPUアーキテクチャの物理的制約がダイレクトに跳ね返る。
TC（Translation Cache）とコード局所性
JITによって生成されたネイティブ命令は、匿名 mmap 領域である TC に書き込まれる。
CPUの命令キャッシュ（L1i）は容量が極めて有限（通常32KB〜64KB）であり、ここに収まりきらない分岐や巨大なメソッドディスパッチは、即座に I-Cache Miss を引き起こし、フロントエンドのパイプラインをガス欠させる。
ここでHackの型システムが重要な役割を持つ。厳格な型（`strict` モード）が強制されている場合、HHVMのJITは動的な型チェック（`instanceof` やメソッドの動的解決）のガードコードを完全に排除し、直値のメモリアクセスや単一の相対分岐（`jmp` / `jne`）にコンパイルできる。これにより、生成されるネイティブコードのフットプリントが劇的に縮小し、L1iキャッシュのヒット率が跳ね上がる。
—
2. データ構造のレイアウトがTLBとL1/L2キャッシュに与える影響
コードがどれほど洗練されていいても、処理対象のデータ構造（Object / Vector / Shape）がメモリ上で散在していれば、CPUはメモリアクセスの待ち時間（Stall）で悶絶することになる。
ポインタチェイスの呪縛とアラインメント
PHP/Hackのオブジェクトは、デフォルトではヒープ上に分散してアロケートされる。オブジェクトAが持つプロパティからオブジェクトBへアクセスする際、CPUはポインタを辿る（Pointer Chasing）。
[ Object A Header ] -> [ Property X ] -> [ Pointer to Object B ]
│
▼
[ Object B Header ] (別メモリ領域)
このポインタチェイスは、L1dキャッシュだけでなく、TLBミス（ページテーブルウォーク）を引き起こす最悪の要因となる。現代のCPUにおいて、TLBミスは数百クロックサイクルのペナルティを伴う。
これを回避するためには、Hack言語のデータ構造において「値の局所性（Spatial Locality）」を意識した設計が不可欠となる。
—
3. 実践：Hackにおけるキャッシュ最適化データ構造の設計
大規模なドメインモデルや高速なストリーム処理をHackで実装する場合、クラスのインスタンスを乱立させるのはJITとキャッシュの観点から愚策である。
以下のコード例は、極限までCPUキャッシュの親和性を高めた「SoA（Structure of Arrays）」的なアプローチを、Hackの型システムとShapeを活用して模倣した設計パターンである。
hh_fixme[6639] // strict mode enforcement
<<__
__
>>
namespace Hack\Optimization\Cache;
type TEntityBatch = shape(
‘ids’ => vec
‘weights’ => vec
‘flags’ => vec
);
/
- 従来のオブジェクト指向的なアプローチ（AoA: Array of Structures）ではなく、
- プリミティブなベクターを並列に保持することで、CPUキャッシュライン（通常64バイト）に
- 連続したデータをアロケートし、ハードウェアprefetcherの恩恵を最大限に引き出す。
/
final class EntityCacheOptimizedEngine {
private TEntityBatch $batch;
public function __construct(int $capacity) {
// 事前にメモリを確保し、断片化を防ぐ
$this->batch = shape(
‘ids’ => vec[],
‘weights’ => vec[],
‘flags’ => vec[],
);
}
public function addEntity(int $id, float $weight, int $flag): void {
// vecの末尾追加はHHVM内部で効率的なcontiguous memory reallocationが行われる
$this->batch[‘ids’][] = $id;
$this->batch[‘weights’][] = $weight;
$this->batch[‘flags’][] = $flag;
}
/
- JITコンパイラが最も最適化しやすい、純粋な数値演算ループ。
- 境界チェックの排除と、連続したメモリアクセスにより、
- L1/L2データキャッシュのヒット率が極限まで高まる。
/
public function processHotLoop(): float {
$weights = $this->batch[‘weights’];
$flags = $this->batch[‘flags’];
$count = \count($weights);
$accumulated = 0.0;
for ($i = 0; $i < $count; ++$i) { // ビット演算と連続した配列アクセス // HHVMのJITはこのループをアンロールし、AVX等のベクトル命令にマッピングする可能性を持つ if (($flags[$i] & 0x1) === 1) { $accumulated += $weights[$i] 1.15; } else { $accumulated += $weights[$i] 0.85; } } return $accumulated; } }
このコードがHHVM/JIT上で最強のパフォーマンスを発揮する理由
1. 連続したメモリ空間（Contiguous Memory）:
`vec
2. 型推論の完全性:
変数がすべて厳格なプリミティブ型（`int`, `float`）として静的に確定しているため、JITはHHVMのボックス化（boxed values：`TypedValue` 構造体）のオーバーヘッドをバイパスし、生のレジスタ演算にコンパイルできる。
3. 分岐予測の最適化:
ループ内の条件分岐がシンプルであるため、CPUのBranch Predictorがハズレを引く確率が激減し、パイプラインのストールが回避される。
—
4. チーフアーキテクトからの提言：メモリレイアウトを支配せよ
Hack言語の静的型チェッカー（hhvm / hh_server）は単なるバグ発見ツールではない。それは「CPUに対して、このデータは完全に予測可能で構造化されている」と宣言するための契約書である。
大規模なトラフィックを捌く分散バックエンドや、リアルタイム性が要求されるマイクロサービスにおいて、フレームワークの抽象化レイヤーの裏で何が起きているかを想像してほしい。無秩序なオブジェクトの生成は、JITのコードキャッシュを圧迫し、データキャッシュをゴミ箱に変える。
コードを書くときは常に、「いま書いたこの処理は、L1キャッシュの何バイトを消費し、メモリコントローラからCPUレジスタへ至るまでに何個のポインタをジャンプさせられているか」を脳内でトレースせよ。この視点を持ったエンジニアだけが、Hack言語の真の限界突破性能を引き出すことができる。