HHVMのJITとCPUキャッシュの親和性：Hack言語における極限のメモリレイアウト戦略
コードレビューをしていると、機能的には完璧に動くものの、高負荷時にCPUキャッシュミスの嵐を引き起こすデータ構造に遭遇する。PHPの延長線上で配列やオブジェクトを漫然と組み上げているうちは、HHVMの真のポテンシャルを引き出すことはできない。
HHVM（HipHop Virtual Machine）のJIT（Just-In-Time）コンパイラは、Hackの厳格な静的型システムから得られるメタデータを元に、ネイティブの機械語へとシームレスにトランスレーションを行う。しかし、どれほど洗練されたJITコードを生成しようとも、CPUがデータをメモリからフェッチする速度（レイテンシ）が追いつかなければ、プロセッサはパイプラインストールを起こし、無為にサイクルを消費し続けることになる。
今回は、HHVMのJIT実行モデルとCPUキャッシュのハードウェア特性を直結させ、実務のプロダクション環境で秒間数十万リクエストをさばくための「データ構造の配置戦略」を解説する。
—
1. HHVMのメモリ管理とCPUキャッシュの基本原則
現代のCPUアーキテクチャにおいて、L1/L2/L3キャッシュ階層とメインメモリ（DRAM）のアクセスコストの差は絶望的だ。L1キャッシュヒットが数サイクルで終わるのに対し、メインメモリからのフェッチ（キャッシュミス）には数百サイクルを要する。
HHVM上で動くHackのデータは、ヒープ上に動的に確保される。ここで重要なのは、「オブジェクトの論理的な関連性と、物理的なメモリ上の配置（Locality of Reference）は必ずしも一致しない」という点だ。
ポインタ追跡（Pointer Chasing）の悪夢
動的に生成されたオブジェクトの配列を走査する際、各要素がメモリ上のバラバラな位置（非連続領域）に存在する場合、CPUはポインタを辿るたびにキャッシュミスを引き起こす。
[ Object A ] —> (メモリ上の遠隔地) —> [ Object B ] —> (さらに遠隔地) —> [ Object C ]
JITコンパイルされたネイティブコードがどれほど高速にループを展開しても、メモリアクセスの待ち時間（Memory Stall）の前には無力となる。このボトルネックを打破するのが、「構造体の配列（Array of Structures: AoS）」から「配列の構造体（Structure of Arrays: SoA）」、あるいは「フラットなプリミティブ配列」へのシフトである。
—
2. 実務で直面するアンチパターンと改善設計
非同期API連携や高頻度でバッチ処理を行うコンポーネントを想像してほしい。例えば、ユーザーのメトリクス情報を保持し、リアルタイムに集計・処理するケースだ。
❌ 典型的だが非効率な実装（AoS的アプローチ）
オブジェクトの配列としてデータを保持する設計は、OOPの観点からは美しく見えても、キャッシュ効率の観点からは最悪だ。
namespace HackExcellence\CacheOptimization;
class UserMetric {
public function __construct(
public int $userId,
public int $requestCount,
public float $latencyMs,
) {}
}
// 散在したオブジェクトの配列：ポインタ追跡が頻発する
async function processMetricsInefficient(vec
$totalLatency = 0.0;
foreach ($metrics as $metric) {
// $metricのプロパティにアクセスするたびにキャッシュミスのリスク
if ($metric->requestCount > 100) {
$totalLatency += $metric->latencyMs;
}
}
return $totalLatency;
}
なぜ非効率なのか？
HHVMのヒープ上において、`UserMetric`インスタンスは生成順序やGCのコンパクション状況によってメモリ上にバラバラに配置される。ループ内で `$metric->requestCount` や `$metric->latencyMs` にアクセスするとき、CPUキャッシュライン（通常64バイト）の恩恵を十分に受けられない。
—
3. 堅牢かつハイパフォーマンスなプロダクションコード設計
ここからが本題だ。Hackの厳格な型システム（Generics, Shapes, Vec）を駆使し、メモリの局所性を最大化する設計パターンを提示する。
データ構造を「バラバラのオブジェクト」ではなく、「同種データの連続した配列（SoA: Structure of Arrays）」として表現することで、HHVMのJITが生成するネイティブコードのベクトル化（SIMD的な処理）や、L1/L2キャッシュのヒット率を劇的に向上させることができる。
匠の設計：フラット化されたプリミティブ配列によるデータ管理
namespace HackExcellence\CacheOptimization;
/
- キャッシュラインの親和性を最大化するためのデータホルダー。
- 関連する同種データを並列のvec（連続したメモリ領域）に分離して保持する（SoAパターン）。
/
final class MetricBatchStore {
// 各メトリクス要素がインデックスで完全に同期している
public function __construct(
public vec
public vec
public vec
) {}
/
- ファクトリーメソッド：外部APIやDBからの非同期レスポンスをフラットに構築する
/
public static async function fromAsyncApiPayload(
Awaitable
): Awaitable
$rawMetrics = await $apiResponse;
$count = C\count($rawMetrics);
// あらかじめ容量を確定させ、動的なメモリ再割り当て（リロケーション）を排除する
varray_or_darray/vec のプリミティブ操作におけるオーバーヘッドを最小化
$userIds = vec[];
$requestCounts = vec[];
$latenciesMs = vec[];
foreach ($rawMetrics as $m) {
$userIds[] = $m[‘user_id’];
$requestCounts[] = $m[‘requests’];
$latenciesMs[] = $m[‘latency’];
}
return new self($userIds, $requestCounts, $latenciesMs);
}
}
/
- 高速化された集計プロセッサ
- JITコンパイラがループアンロールやレジスタ割り当てを最適に行える構造にする。
/
final class MetricProcessor {
public static function calculateHighTrafficLatencySum(MetricBatchStore $store, int $threshold): float {
$totalLatency = 0.0;
// vecの内部バッファは連続したメモリ領域を指すため、
// CPUはプリミティブな連続アクセス（Sequential Access）としてプリフェッチを極限まで効率化できる。
$counts = $store->requestCounts;
$latencies = $store->latenciesMs;
$size = C\count($counts);
for ($i = 0; $i < $size; ++$i) {
if ($counts[$i] > $threshold) {
$totalLatency += $latencies[$i];
}
}
return $totalLatency;
}
}
—
4. この設計がHHVM JITとCPUにもたらす恩恵
1. CPUハードウェアプリフェッチャの活性化
`vec
2. JITコンパイルの最適化（Type Specialization）
Hackの `int` と `float` はプリミティブ型として扱われ、ボクシング（Boxed Values：ヒープ上のラッパー構造体に包むこと）のオーバーヘッドが回避される。JITはこれらを直接CPUレジスタに載せ、余分な型チェックのガード命令を排除したネイティブコードを出力する。
3. GC（ガベージコレクション）の負荷軽減
無数の小さなオブジェクト（`UserMetric`のインスタンス群）の生成・破棄を繰り返すと、ヒープの断片化（Fragmentation）を招く。フラットな `vec` を再利用する設計にすることで、メモリの局所性が保たれ、GCのストップ・ザ・ワールド時間を極小化できる。
—
チーフアーキテクトからの提言
「きれいにオブジェクト指向でモデリングすること」と「ハードウェアの物理特性に逆らわないこと」は、高負荷なWebシステムにおいてしばしばトレードオフになる。
しかし、Hack言語の強靭な型システムとHHVMのアーキテクチャ特性を深く理解していれば、「ドメイン層では美しく型安全に表現しつつ、パフォーマンスクリティカルなデータ処理パイプラインではメモリレイアウトをフラットに最適化する」というハイブリッドな設計が可能になる。
コードレビューの際は、単に「正しく動くか」を見るな。
「そのデータ構造は、CPUキャッシュに愛されているか？」という視点を持って、コードの奥底にあるメモリの流動を感じ取ってほしい。