ガベージコレクションの停止時間制御（低レイテンシGC）

停止時間はどこで生まれるか

トレース型GCの基礎と世代別・並行マークの仕組みはガベージコレクションアルゴリズムの内部で扱いました。本稿はその先、停止時間（pause time）をヒープ規模から切り離すための具体機構に踏み込みます。

GCの一時停止は大きく3つのフェーズから生じます。ルートスキャン（スタックやレジスタの参照を拾う）、マーク（到達可能性の探索）、そしてコンパクション（生存オブジェクトを詰めて断片化を解消する移動）です。このうちマークとコンパクションはヒープに比例して重くなります。G1までの世代別GCは並行マークでマークのSTWを削りましたが、コピー（evacuation）は依然STWで行うため、ヒープが大きく生存量が多いほど停止が伸びます。

低レイテンシGC（ZGC・Shenandoah・Azure C4）の核心は、このコンパクションまでアプリ（mutator）と並行に実行することです。すると問題は「移動の最中にアプリが古いアドレスを掴んでいたらどうするか」という一点に集約されます。これを解くのがカラーポインタと読み取りバリアです。

並行コンパクションの本質的な難しさ

オブジェクトを別のアドレスへ移すと、それを指す全参照を新アドレスへ張り替えねばなりません。STWなら世界が止まっているので一括で書き換えられますが、並行だとアプリが同じ参照を読み書きし続けます。素朴にやれば、移動済みオブジェクトの古いコピーを読むスレッドと新コピーを読むスレッドが混在し、一貫性が壊れます。

カラーポインタ — 参照に状態を埋める

64ビットアドレス空間では、実際に使うアドレスビットは48ビット前後で十分です。カラーポインタ（colored pointer）は、ポインタの未使用ビットにGCのメタデータ（色）を埋め込む手法です。ZGCは下位ビット群に Marked0 / Marked1 / Remapped / Finalizable といった色を持たせ、その参照が「現在のGCサイクルでマーク済みか」「移動先へ張り替え（remap）済みか」を参照値そのものから即座に判定できるようにします。

// ZGC のカラーポインタ（概念図、ビット配置はバージョンで異なる）
[ 未使用 | 色ビット(Marked0/Marked1/Remapped) | 48bitの実アドレス ]

ref を辿るとき:
  if 色 が「現在の良い色」と一致 -> そのまま使える（高速パス）
  else                         -> 読み取りバリアで修復（低速パス）

色を参照に持たせる利点は、オブジェクトのヘッダを書き換えずに状態を表せる点と、判定がポインタのビットマスク比較だけで済む点です。同じ物理オブジェクトを指していても、ビューによって色（=アドレスの別名）が異なる「多重マッピング」を使う実装もあり、ZGCの初期実装はOSの仮想メモリ機能で同一ページを複数アドレスに写像していました（後の世代別ZGCはこれをやめ、ビット比較主体に変更）。仮想アドレス変換の前提は仮想メモリとページングが背景になります。

読み取りバリア — 辿る瞬間に正規化する

世代別GCのwrite barrier（書き込みフック）に対し、低レイテンシGCの主役は読み取りバリア（load barrier）です。ヒープから参照を読み出すたびに短いコードが挿入され、その参照の色を検査します。

// load barrier の概念（参照読み出しをフック）
Object load(field) {
    ref = *field;                  // 生の参照を読む
    if (color_ok(ref)) return ref; // 高速パス: ビット比較のみ
    // 低速パス: 移動済みなら新アドレスへ、未マークならマーク登録
    ref = slow_path(field, ref);   // 必要なら forwarding を辿る
    *field = ref;                  // self-healing: 参照を新値に上書き
    return ref;
}

決定的に重要なのが最後の上書き、**self-healing（自己修復）**です。低速パスで新アドレスを得たら、それを元のフィールドへ書き戻します。すると同じ参照に対する次回以降の読み出しは高速パスを通り、二度と修復が要りません。修復は「触れた参照」にだけ遅延的に課金され、ヒープ全体を一括で書き換える必要がない——これが停止時間をヒープ規模から切り離す要石です。フィールド書き戻しは複数スレッドが競合し得るためアトミックなCAS等で行います（ロックフリーとCAS命令）。

なぜミリ秒級で止まるのか — 計算量の分解

STW区間に残る仕事を分解すると、なぜ停止がヒープに依存しないかが明確になります。

STWに残るのはルートスキャンや弱参照処理といったヒープサイズに対してほぼ定数の仕事だけです。重いマークと移動は並行フェーズに追い出されているため、ヒープが8GBでも数百GBでも、止まる時間は「ルート数とリージョン管理のメタ作業」で決まります。ZGCはこの設計でサブミリ秒〜数ミリ秒、C4（Azul Zing）はTB級ヒープでも一貫した低停止を公称します。停止時間の評価は最悪値（テールレイテンシ）で見るべきで、平均ではなくp99・p999が意味を持つ点も実務上の要点です。

三者の共通原理と相違

ZGC・Shenandoah・C4は実装が異なりますが、並行マーク＋並行コンパクション＋参照を辿る瞬間の正規化という骨格を共有します。

いずれも、参照の有効性をオブジェクトではなく参照値の側で表現し、アクセス時に修復するという発想に収束しています。世代別GCが「いつ・どこを回収するか」で停止を抑えたのに対し、低レイテンシGCは「移動という最重量作業をどう並行化するか」で停止を抑える、というのが分水嶺です。

まとめ

低レイテンシGCは、停止の主因であるコンパクション（オブジェクト移動）をアプリと並行に実行することで成立します。並行移動の一貫性は、参照の未使用ビットに移動状態を刻むカラーポインタと、参照を辿る瞬間に色を検査し古い参照を新アドレスへ書き戻す読み取りバリアのself-healingが担保します。これにより、ヒープ全体の一括書き換えが不要となり、STWに残るのはルートスキャン等のヒープ非依存な定数仕事だけになります。結果として停止時間はヒープ規模からほぼ独立し、数百GB級でもミリ秒級に収まります。ただしこれはバリアコスト・スループット低下・allocation stall という対価の上に成り立つ設計であり、停止・スループット・フットプリントの三角形のどこを取るかという選択であることは、世代別GCから一貫して変わりません。