「ガーベジコレクションにおけるCPUとメモリの関係を解剖する（OpenJDK 26）」

1 背景

リスプでガーベジコレクション（GC）が約70年前に普及して以来、マネージドランタイムは開発者に「自動メモリ管理」という魔法のようなものを提供しました。これによりプログラマは複雑なライフサイクル管理から解放され、Smalltalk の設計にも影響を与えました。この流れをたどり、Java（私が日々改善している言語とランタイム）の作者も Smalltalk を含むいくつかの言語に触発されたと言われています。

プログラマは解放されても CPU はそうではありませんでした。GC がメモリを回収するために重要な経路（クリティカルパス）に位置し、永遠に遅延できない負債を抱えるようになりました。数十年にわたり、この負債を解消するにはアプリケーション全体を一時停止させる「ワールドストップ」が必要でした。コレクタはアプリを停止し、ヒープを走査して再利用可能なメモリを特定・回収します。シングル‑コア時代では、このポーズ時間がマシンの負荷を測る信頼できる代理指標となっていました。

1.1 GC コストの分類

GC のパフォーマンスへの影響を考えるために、次の3つの観点（図 1）に分解します。

void update(Node n){ n.next = newNode; }

if(GC.isMarking){ GC.enqueue(n.next); // Pre‑Barrier }<br>n.next = newNode;<br>GC.updateCard(n); // Post‑Barrier

• 明示的 GC コスト：オブジェクトグラフのトラバーサルやメモリ移動、参照更新など、専用 GC スレッドが消費する CPU サイクルです。
• 暗黙的 GC コスト：参照カウントや世代別追跡、並行移動時のヒープ整合性を維持するためにアプリコードに挿入されるバリアです。
• マイクロアーキテクチャ的影響：GC が CPU キャッシュからアプリデータを排除したり、オブジェクト配置を再編成して空間局所性を改善することでパフォーマンスに影響します。

暗黙的 GC コストの測定は難しいです。Blackburn と Hosking（2004）は Jikes RVM を拡張しバリアなしのベースラインを確立しましたが、その手法は OpenJDK などの性能最適化された VM には簡単に移行できません。

1.2 シングルスレッドポーズ

OpenJDK では Serial GC がクラシックなシングルコア戦略を示します。ヒープが満杯になると、アプリケーションの実行は完全に停止し、コレクタがスペースを回収します（図 2）。これによりメモリ圧力がポーズ時間へ変換されます。

ウォールクロック vs. CPU 時間

• ウォールクロック時間 = 実際に経過した実行時間。
• CPU 時間 = アプリケーションを実際に実行していた CPU の合計時間。

シングルスレッドで計算量が多い場合、これらの指標はほぼ一致します。マルチコア環境では分離し、比率 ( \frac{\text{CPU time}}{\text{wall‑clock time}}) は実行中に平均して使用されたコア数を近似します。この区別はパフォーマンス分析で重要です：応答性と効率性を切り離すことができます。

長いポーズは破壊的だったため、我々はそれらを排除する設計を行いました。世代仮説や毎回のポーズスパイクを警告するダッシュボード、そして厳密な定義―「アプリケーション時間は生産的であり、ポーズ時間はオーバーヘッドである」―に基づいています。バッチ処理というメンタルモデルがトレードオフを明確化しました：メモリはスループットを買うものです。ヒープを拡張すればコレクションを遅らせ、総ポーズコストを減らします；逆にメモリ制限すると頻繁なコレクションが発生し、CPU サイクルを消費してアプリケーションを維持することになります（図 3）。

しかし図 3 には二つの欠陥があります：

1. スループットはポーズ時間だけで決まるわけではない – 各 GC ラウンドはサーフポイントペナルティ（スレッド同期コスト）を伴います。高頻度になると観測可能なオーバーヘッドに蓄積します。
2. ポーズ時間 ↔ ユーザー遅延の関係が崩れる – インターバルが短くなるほど、アプリケーション機能は複数回中断される可能性が高まります。累積遅延は単一停止ではなく、中断の合計に依存します。

実際にはピーク時のウェブサーバーを考えると、高 GC 周波数は短いポーズを蓄積したスタッタへ変換し、スムーズな相互作用がフラストレーションのある待ち時間へと転化します。

1.3 マルチスレッドポーズ

マルチコア CPU は二つの選択肢を提供しました：ブートフォースでポーズ（並行性）か、アプリケーションと同時に実行する（コンカレンシー）。Parallel GC は利用可能なすべてのコアを使い、ポーズ時間を短縮します。Serial GC のマルチスレッド化版です。二重コアインスタンスではポーズが半減しますが（図 4）、GC 全体の CPU 時間は一定であり、単に作業が並列化されているだけです。このためシングルスレッドのアプリケーションフェーズ中にアイドルコアが発生し、プロビジョニング非効率が生じます。

1.4 バッチ処理からバックグラウンド作業へ

Parallel GC のポーズ短縮はライブセットサイズと Amdahl の法則（図 5）に制限されます。多くのコアを使っても、シリアル部分が小さいほどスピードアップは限定的です。64 コアで最大約 39 倍までしか伸びません。したがって、単にハードウェアを増やすだけではポーズ問題を解決できません。

1.5 G1：バックグラウンド作業へ移行

G1 はポーズから作業をシフトし、並列バッチ処理とコンカレンシーのハイブリッドです（図 6）。GC コストをポーズ中にのみ測定すると総努力を過小評価します。このワークロードでは GC CPU 時間の 79 % がアプリケーション実行時に並列で発生しています。G1 は「並列化されたバッチ処理 + バックグラウンド作業」のハイブリッドですので、ポーズ時間は不完全な指標となります。

1.6 ZGC：オーバーヘッドとポーズを切り離す

ZGC は重い作業（オブジェクト移動）を並行して実行し、ヒープサイズに関係なくサブミリ秒のポーズを実現します（図 7）。ポーズ時間と GC オーバーヘッドの相関はほぼ切り離されました。バックグラウンドスレッドとアプリケーションスレッドで作業が分散され、ロードバリアにより調整されています。ZGC のコストを測る際にポーズ時間だけを頼るのは誤りです。

1.7 まとめ

各世代ごとに GC ポーズ時間とマシンリソースとの相関が弱まります：

• Parallel GC はポーズを半減させますが、プロビジョニング非効率が増します。
• G1 は 79 % のサイクルをバックグラウンドへ移動し、スループットオーバーヘッドを隠蔽します。
• ZGC は指標を完全に切り離し、サブミリ秒のレイテンシが低いことと計算負荷が少ないことは必ずしも一致しません。

データセンターでは CPU サイクルの大部分が低レベル操作（シリアライズ、メモリ割当）に費やされます。GC がその税金を支配します。総プロセス CPU 時間だけを測定しても、計算集約型アプリコード、積極的な JIT コンパイラ、あるいは苦戦する GC を区別できません。コレクタの作業を内部で正確に追跡し、ヒープサイズのチューニングと効率性理解に不可欠です。

2 標準 Java API で明示的な GC コストを計測する方法

OpenJDK 26 では次の二つの機構で明示的 GC コストを定量化できます：

1. -Xlog:cpu

   を用いた統一ログ（JVM 終了時に出力）。
2. Java API メソッド

   MemoryMXBean.getTotalGcCpuTime()

   。

どちらも新しい

cpuTimeUsage.hpp

研究者やエンジニアは次のパターンでこのテレメトリを取得できます：

import com.sun.management.OperatingSystemMXBean;
import java.lang.management.ManagementFactory;
import java.lang.management.MemoryMXBean;
import java.util.concurrent.Executors;
import java.util.stream.IntStream;

public class Main {
    static final MemoryMXBean memoryBean =
        ManagementFactory.getPlatformMXBean(MemoryMXBean.class);
    static final OperatingSystemMXBean osBean =
        ManagementFactory.getPlatformMXBean(OperatingSystemMXBean.class);

    public static void main() {
        // JIT ウォームアップ等を考慮し 10 回実行
        for (int i = 0; i < 10; i++) {
            long start     = System.nanoTime();
            long startGC   = memoryBean.getTotalGcCpuTime();
            long startProc = osBean.getProcessCpuTime();

            try (var executor =
                     Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors())) {

                IntStream.range(0, 100_000).forEach(_ -> {
                    App app = new App();
                    executor.submit(app::critical);
                });
            }

            long end     = System.nanoTime();
            long endGC   = memoryBean.getTotalGcCpuTime();
            long endProc = osBean.getProcessCpuTime();

            long duration  = end - start;
            long gcCPU     = endGC - startGC;
            long procCPU   = endProc - startProc;

            System.out.println("GC used " +
                String.format("%.2f", 1.0 * gcCPU / duration) + " cores");
            System.out.println("Process used " +
                String.format("%.2f", 1.0 * procCPU / duration) + " cores");
            System.out.println("GC used " +
                (int)(100.0 * gcCPU / procCPU) + "% of total CPU spend");
            System.out.println("---------------------------------");
        }
    }
}

class App {
    byte[] a;
    void critical() { a = new byte[100_000]; }
}

getTotalGcCpuTime()

getProcessCpuTime()

短時間実行アプリケーション
JVM は OS の CPU‑time アカウンティングに依存します。数ミリ秒程度の極端な短い実行では結果が不安定になる可能性があります。

3 Xalan と Spring への CPU コスト計測の適用

上記テレメトリパターンを使い、Intel Xeon Gold 6354（18 コア、36 スレッド、39 MB LLC）で DaCapo ベンチマークスイートの Xalan と Spring を走らせました。デフォルトの DaCapo プロビジョニングはハードウェアスレッドごとに 1 アプリケーションスレッドを割り当てますが、すべて 36 スレッドを飽和させるわけではありません。低いヒープサイズでは GC がクリティカルパスになるため、使用されるコア数が少なくなります。従来はポーズ時間で GC の負荷を推測していましたが、今こそ真の計算コストを明らかにできます。

• Xalan – CPU‑メモリトレードオフ（図 8）：性能はメモリ不足と相関します。39 MB の壁で大幅な向上が得られ、その後は減衰します。しきい値を超えると Amdahl の法則が支配し、プロセス CPU 使用率は上昇するもののスループット改善は停滞します。GC CPU オーバーヘッドに「正解」が存在するわけではなく、メモリ制約が主であれば Parallel が 19 MB ヒープで 79 % の CPU を GC に費やしても許容できるケースがあります。

• G1 vs. Parallel – 最小ヒープでは G1 は Parallel より 65 % 少ない CPU を使用し、同等のスループットを提供します。ZGC は制約あるヒープでより多くのベースメモリを必要としますが、十分なヘッドルームがあれば G1/Parallel と同等に機能します。このトレードオフは「メモリ足跡 vs. 最小アプリケーションレイテンシ」という設計選択を反映しています。

• Spring PetClinic – 動的変化（図 9）：202 MB と 405 MB で G1 はスループット維持のために約 3.5 倍多く CPU を消費します。これは Xalan の効率性と対照的です。ZGC はヒープが大きくなるにつれて Parallel/G1 に近づきますが、405 MB では「ストーム」と呼ばれる割当停止に直面し、コンカレンシーコレクタのアンチパターンとして線形化されたリロケーション作業がアプリスレッドを停止させます。

4 結論

長い間、明示的 GC CPU オーバーヘッドを理解するには侵襲的なプロファイリングやカスタムビルドが必要でした。OpenJDK 26 で

MemoryMXBean.getTotalGcCpuTime()

-Xlog:cpu

• 研究者 – 比較研究用の標準ベースラインを提供し、ノイズを削減。
• エンジニア – ヒープサイズチューニングや Amdahl 制限の検出を実際運用で観測。

JDK に組み込まれたツールを使い、プロダクションシステムと研究論文の両方に厳密な計算コスト算定をもたらしましょう。

5 参考文献

1. S.M. Blackburn & A.L. Hosking, “Barriers: Friend or Foe?” ISMM, 2004。
2. D. Ungar, “Generation Scavenging: A Non‑Disruptive High Performance Storage Reclamation Algorithm,” SDE 1, 1984。
3. P. Cheng & G.E. Blelloch, “A Parallel, Real‑Time Garbage Collector,” PLDI, 2001。
4. G.M. Amdahl, “Validity of the single processor approach to achieving large scale computing capabilities,” AFIPS, 1967。
5. D. Detlefs et al., “Garbage‑first garbage collection,” ISMM, 2004。
6. S. Kanev et al., “Profiling a warehouse‑scale computer,” ISCA, 2015。
7. W. Hassanein, “Understanding and Improving JVM GC Work Stealing at the Data Center Scale,” ISMM, 2016。