HHVMのJITとCPUキャッシュの深層：データ局所性を極限まで高めるHackコード配置戦略
コードレビューをしていると、静的型システムを完全に理解し、`Shapes`やベクタを美しく使いこなしているエンジニアであっても、ハードウェアの物理制約、特に「CPUキャッシュ」のレイヤーまで意識してコードを書けている者は少ない。
HHVM（HipHop Virtual Machine）は、Hackの厳格な型情報をコンパイルパイプラインの武器とし、圧倒的なスループットを叩き出す。しかし、どれほど洗練されたJIT（Just-In-Time）コンパイル構造を持っていようとも、CPUがメインメモリ（DRAM）へのフェッチを余儀なくされる瞬間、パイプラインは泡を吹いて停止する。L1/L2キャッシュミスの代償は、現代のCPUサイクルにおいては致命傷だ。
今回は、HHVMのJIT生成コードとデータ構造のメモリレイアウトがCPUキャッシュにどう作用するのか、そして極限のパフォーマンスを引き出すためのHackコード配置戦略を、チーフアーキテクトの視点から叩き込む。
—
1. HHVM JITとCPUキャッシュの物理的現実
HHVMは、Hackのバイトコードを一度プロファイル誘導最適化（PGO: Profile-Guided Optimization）を経由し、x86-64ネイティブ機械語へと翻訳する。この時、JITエンジンが生成したマシンコード（TC: Translation Cache）と、そこで処理されるヒープ上のデータ（オブジェクト、配列、構造体）がCPUのキャッシュライン（通常64バイト）をいかに効率よく埋めるかが、スケーラビリティの境界線となる。
ポインタの迷宮（Pointer Chasing）という悪夢
オブジェクト指向プログラミングにおいて、次のようなコードは日常茶飯事だろう。
class Node {
public ?Node $next = null;
public int $value = 0;
}
この構造をヒープ上に素朴に配置していくと、各インスタンスはメモリ上のバラバラなアドレスに散らばる。結果として、CPUが `$node->next` を辿るたびにL1/L2キャッシュミスが発生し、CPUは数百サイクルのウェイト（Memory Stall）を強制される。JITがどれほど高速なネイティブコードを生成しても、データがキャッシュに乗っていなければCPUは遊ぶのだ。
—
2. 空間的局所性（Spatial Locality）を最大化するデータ構造設計
このハードウェアの制約を突破する唯一の手段が、「データの連続配置（Contiguous Allocation）」である。HHVMの配列や、Hackの強力な構造体的なアプローチである `shape`、あるいはプリミティブを詰めたベクタを活用し、メモリ上の物理的距離を詰める必要がある。
実務の現場で、非同期API連携や大量のペイロード処理を行うコアコンポーネントを設計する際の手法を見ていこう。
悪い例：散在するオブジェクトの走査
namespace HackArchitecture\CacheOpt;
class BadMetricPoint {
public function __construct(
public int $timestamp,
public float $value,
) {}
}
// 散在するインスタンスの配列：最悪のキャッシュ効率
function process_scattered_metrics(vec
$sum = 0.0;
foreach ($points as $point) {
// 各イテレーションでポインタをデリファレンスするためL1キャッシュミス頻発
$sum += $point->value;
}
return $sum;
}
なぜ非効率なのか： `vec
—
良い例：プリミティブのパッキングとSoA（Structure of Arrays）戦略
ハードウェアのキャッシュラインを極限まで有効活用するためには、データを構造体の配列（AoS）ではなく、配列の構造体（SoA）、あるいは単一の密なベクタにパックすべきだ。
以下のプロダクションコードは、高スループットが要求される時系列データの処理において、データ局所性を最大化する設計パターンである。
namespace HackArchitecture\CacheOpt;
/
- CPUキャッシュの空間的局所性を極限まで高めたメトリクス処理エンジン
- 【設計のポイント】
- オブジェクトのインスタンス化を排除し、プリミティブな型（int, float）の
- 連続したベクタ（vec）としてデータを保持することで、HHVMのJITが
- SIMD命令や効率的なレジスタ割り当てを行えるメモリレイアウトを強制する。
/
final class DenseMetricsEngine {
// タイムスタンプと値を別々の連続メモリ領域（SoAパターン）に保持
private vec
private vec
public function __construct(int $capacity = 1024) {
// 事前に容量を確保し、ヒープの再割りallocate（realloc）コストを抑制
$this->timestamps = vec[];
$this->values = vec[];
}
public function ingest(int $timestamp, float $value): void {
$this->timestamps[] = $timestamp;
$this->values[] = $value;
}
/
- キャッシュヒット率を最大化したバッチ演算処理
- CPUのL1キャッシュライン（64バイト）にfloat（8バイト）が連続して
- 8個ずつ隙間なく乗るため、プリフェッチャーが完全に機能する。
/
public function computeOptimizedMovingAverage(): float {
$count = \count($this->values);
if ($count === 0) {
return 0.0;
}
$sum = 0.0;
// JITコンパイラがこの単純なインデックスアクセスループを極限まで最適化する
for ($i = 0; $i < $count; ++$i) {
$sum += $this->values[$i];
}
return $sum / $count;
}
}
—
3. 保守性とパフォーマンスを両立するアーキテクチャ上の注意点
実務でこの設計を導入する際、以下のトレードオフと設計原則をコードレビューで厳守させること。
1. カプセル化の神話に囚われない
「オブジェクト指向的に美しく」小分けされたクラス設計は、Webアプリケーションのドメイン層では有効であっても、インフラストラクチャ層や高スループットなデータパイプラインにおいてはパフォーマンスの癌になる。データの密着性を優先し、プリミティブの並びを直接操作する設計を恐れてはならない。
2. HHVMのJITトレーシング特性を理解する
HHVMのJITは、型が完全に静的に確定しているコード片（Hackの厳格な型付け `<
3. アロケーションの局所化（Arena Allocation的発想）
リクエストライフサイクル内で頻繁に生成・破棄されるデータ構造は、極力ローカルスコープで完結させ、グローバルなヒープ汚染を防ぐ。Hackの `vec` や `keyset` のイミュータブルな特性を活かし、メモリの断片化（Fragmentation）を防ぐことが、L2/L3キャッシュのヒット率維持に直結する。
—
チーフアーキテクトからの総括
コードの美しさは、可読性だけにあるのではない。「そのコードがハードウェア上でどう振る舞うか」という物理的実感が伴って初めて、真に美しいプロダクションコードと呼べる。
HHVMとHackの静的型システムは、我々に強力な武器を与えてくれた。ポインタの迷宮からデータを救い出し、CPUキャッシュの波に乗せるためのデータ構造設計——これを次のスプリントから君たちのコードベースに導入せよ。妥協のないアーキテクチャだけが、スケール時の絶望を防ぐ唯一の盾となる。