Jade: A High-throughput Concurrent Copying Garbage Collector
Jade：一种高吞吐并发复制垃圾收集器

ACM Reference Format:  ACM 文献引用格式:

1 Introduction  1 引言

• A detailed analysis of pauses in concurrent collectors to uncover their deficiencies in design (§2);
  对并发回收器中暂停现象的详细分析，揭示其设计缺陷（§2）；
• Jade, a concurrent generational collector leveraging group-wise collection to achieve both high GC efficiency and low pauses (§3-4);
  Jade——一种利用分组回收实现高 GC 效率与低暂停的并发分代回收器（§3-4）；
• Comprehensive evaluation with representative latencysensitive applications (including commercial online services) to show Jade’s improvement over state-of-the-art collectors (§5).
  通过典型延迟敏感应用（含商业在线服务）的全面评估，展示 Jade 相较前沿回收器的改进（§5）；

2 Analysis on Concurrent Copying GC
2 并发复制式垃圾回收分析

2.1 Concurrent copying garbage collectors
2.1 并发复制垃圾回收器

2.2 Characterizing pauses in concurrent copying collectors
2.2 并发复制收集器的停顿特征分析

2.3 Shenandoah: heap-wise collection
2.3 Shenandoah：堆式回收机制

Shenandoah tends to treat the whole heap as a monolithic unit. Figure 1 illustrates three major phases in Shenandoah. The first marking phase traverses all equal-sized regions inside Shenandoah’s heap to locate live objects and store their
Shenandoah 倾向于将整个堆视为单一整体。图 1 展示了 Shenandoah 的三个主要阶段：初始标记阶段会遍历堆内所有等大小的区域，定位存活对象并存储其

• Longer pre-reclamation cycle. Since Shenandoah only maintains live objects’ information in a simple bitmap, it does not know exactly which objects hold references to copied ones. Therefore, GC threads have to check all live objects for reference updates, and free regions can be reclaimed only when all phases are finished, which lengthens the time before the memory resources can be reused (we refer to this cycle as a prereclamation cycle). Meanwhile, each live object needs to be accessed at least three times in one GC cycle, which adds more performance overhead and also affects the duration of pre-reclamation.
  更长的预回收周期。由于 Shenandoah 仅通过简单位图维护存活对象信息，无法精确掌握哪些对象持有对复制对象的引用。因此垃圾回收线程必须检查所有存活对象以更新引用，且只有待所有阶段完成后才能释放内存区域，这延长了内存资源可被重复利用前的等待时间（我们称此周期为预回收周期）。此外，每个存活对象在单次 GC 周期中至少需被访问三次，这不仅增加了性能开销，也影响了预回收阶段的持续时间。
• Higher collection frequency. Shenandoah’s reclamation efficiency heavily relies on the number of free regions in its one-generation heap. If the heap only contains a few free regions, the number of reclaimed bytes is limited, and the frequency of GC would increase.
  更高的回收频率。Shenandoah 的回收效率高度依赖于其单代堆中空闲区域的数量。当堆内存仅剩少量空闲区域时，可回收的字节数将受到限制，从而导致垃圾回收频率上升。

2.4 ZGC: region-wise collection
2.4 ZGC：基于分区的收集机制

This region-wise design seems to shorten the prereclamation cycle by moving evacuation and reference updating off the critical path. Unfortunately, the application stall becomes even longer as shown in Table 1. Although ZGC’s pre-reclamation only contains the marking phase,
这种分区设计通过将疏散和引用更新移出关键路径，似乎缩短了预回收周期。但如表 1 所示，应用程序停顿时间反而变得更长。尽管 ZGC 的预回收仅包含标记阶段，

2.5 Discussion: generational variants
2.5 讨论：分代变体

2.6 Summary  2.6 总结

3 Group-wise design in Jade
3 Jade 中的分组式设计

3.1 Overview  3.1 概述

3.2 Simulation-based hand-over-hand grouping
3.2 基于模拟的递进式分组算法

3.3 Group-wise remembered sets
3.3 分组记忆集

Algorithm 1 Constructing collection groups
    for region in old_regions do
        if region.live_bytes/region.size_bytes <
            threshold then
                tracked_list.add(region)
        end if
    end for
    \# Sorting the tracked regions (organized as a list) by the
    size of live bytes
    tracked_list.sort()
    free_bytes \(\leftarrow\) estimate_free_space()
    while !tracked_list.is_empty() do
        group \(\leftarrow\) empty
        if groups.is_empty() then
            \# Constructing the first group
            while !tracked_list.is_empty() do
                region \(\leftarrow\) tracked_list.take_first ()
                free_bytes \(\leftarrow\) free_bytes-
                        region.live_bytes
                if free_bytes < 0 then
                    break
                end if
                group.add(region)
            end while
            group_size \(\leftarrow\) group.size ()
        else
            \# Constructing subsequent groups
            while group.size () < group_size do
                if tracked_list.is_empty() then
                    break
                end if
                group.add(tracked_list.take_first())
            end while
        end if
        groups.add(group)
        if groups.size() >= MAX_GROUP then
            break
        end if
    end while
    \# Output groups

Although enabling incremental reclamation, remembered sets have three disadvantages compared with color pointers. First, since the references are memorized in a coarse (card-level) granularity, GC threads have to scan more objects to find and update cross-region references. Second, the memory overhead is proportional to the number of regions, which can be quite large (usually more than thousands). Third, remembered sets need to be rebuilt after each marking phase, which potentially lengthens the prereclamation cycle. To mitigate the first two problems, fade provides group-wise remembered sets, where regions in the same group share a remembered set. Since regions in the
尽管记忆集支持增量回收，但与颜色指针相比存在三个缺点。首先，由于引用是以粗粒度（卡表级）记录的，GC 线程不得不扫描更多对象来查找和更新跨区域引用。其次，内存开销与区域数量成正比，而区域数量可能非常庞大（通常超过数千个）。第三，每次标记阶段后都需要重建记忆集，这可能会延长预回收周期。为缓解前两个问题，Fade 提供了分组式记忆集，同组区域共享一个记忆集。由于同组区域会
same group are released together, we do not need to memorize inter-region references inside them, which reduces the re-scanning overhead. Meanwhile, the memory overhead is also reduced as the number of groups is much smaller. Since each bitmap consumes only $1/4096$$1/4096$1//40961 / 4096 of the heap size, the overall memory overhead is only $0.39\mathrm{\%}$$0.39\mathrm{\%}$0.39%0.39 \% for 16 groups.
被整体释放，我们无需记录组内区域间的引用，从而降低了重复扫描开销。同时，由于组数量远少于区域数量，内存开销也得以降低。每个位图仅占用堆内存的 $1/4096$$1/4096$1//40961 / 4096 ，因此 16 个分组的总内存开销仅为 $0.39\mathrm{\%}$$0.39\mathrm{\%}$0.39%0.39 \% 。

4 Generational collection
4 分代回收

4.1 Single-phase young GC
4.1 单阶段年轻代 GC

4.2 Free space estimation
4.2 空闲空间估算

Algorithm 2 Estimating free space size for collection
    function ESTIMATE_FREE_SPACE
        free_space \(\leftarrow\) free_region_count \(*\) region_size
        free_space \(\leftarrow\) free_space - promotion_ratio*
            estimated_gc_time
        free_bytes \(\leftarrow\) free_space \(*(1-\) young_ratio \()\)
        return free_bytes
    end function

4.3 Chasing mode and full GC
4.3 追赶模式与完全 GC

4.4 Weak references handling
4.4 弱引用处理

5 Evaluation  5 性能评估

5.1 Experiment setup  5.1 实验配置

• Specjbb2015 [12] is the de facto standard for Java server performance, especially for garbage collectors. It simulates an online supermarket serving various kinds of requests. Both ZGC and Shenandoah adopt this application to show their improvement against prior collectors upon their release [15, 22]. Meanwhile, Oracle leverages it as the primary application to show the progress of GC in OpenJDK [19, 30].
  Specjbb2015[12]是 Java 服务器性能（尤其是垃圾收集器）的事实标准基准。它模拟在线超市处理各类请求的场景。ZGC 和 Shenandoah 发布时都采用该应用展示其相对前代收集器的改进[15,22]。同时 Oracle 也将其作为展示 OpenJDK 垃圾收集器进展的主要测试应用[19,30]。
• HBase [1] is a distributed big-data store for nonrelational data. We mainly use it to study the singlemachine performance, and the evaluated version is 2.4.14.
  HBase[1]是面向非关系型数据的分布式大数据存储系统。我们主要用其研究单机性能，评估版本为 2.4.14。
• Shop is a real-world online service used in Alibaba’s e-commerce platform. This service is used by tens of millions of users every day to serve their requests to access online shops.
  Shop（店铺）是阿里巴巴电商平台中一项真实在线的服务，每天为数千万用户提供访问线上店铺的请求服务。
• DaCapo [2] is a benchmark suite containing various Java workloads. Compared with other evaluated applications, most workloads in DaCapo have smaller memory demand, so we mainly use them to show the performance of Jade with tight memory budgets.
  DaCapo [2] 是一个包含多种 Java 工作负载的基准测试套件。与其他评估应用相比，DaCapo 中的大多数工作负载对内存需求较小，因此我们主要用它来展示 Jade 在严格内存预算下的性能表现。
  With those applications, we mainly compare Jade with four different concurrent garbage collectors: G1, ZGC, Shenandoah, and LXR. G1 and LXR evacuate objects in an STW fashion, so it is helpful to improve application throughput. However, their STW pauses may cause worse application latency especially when the size of live data grows larger. Both ZGC and Shenandoah concurrently evacuate objects and thus have larger interferences on application throughput. All those collectors are also evaluated under OpenJDK-11.0. Since G1 allows users to control its pause time by setting a soft limit (-XX:MaxGCPauseMillis), we manually set it to 10 ms for better application latency, in addition to a default setting $(200\mathrm{ms})$$(200\mathrm{ms})$(200ms)(200 \mathrm{~ms}). We also evaluate the generational variants of ZGC and Shenandoah (namely GenZ and GenShen), and the respective versions are OpenJDK21 and OpenJDK-22 ${}^1$${}^1$^(1){ }^{1} since they do not backport to older versions. As GenZ and GenShen are implemented in different JDK versions, the evaluation results would be affected by other factors other than GC (e.g., efficiency of JIT optimizations). LXR is built from its latest commit (the commit number for mmtk-core and mmtk-openjdk is 4 ab 99 bb and cdbc8de, respectively), which is also based on OpenJDK11.0 (commit 7caf8f7). The mmtk/opt cargo feature is also enabled to avoid performance issues. C4 is not included as it uses a similar algorithm to GenZ but a much different JDK implementation (Azul JDK).
  在这些应用中，我们主要将 Jade 与四种不同的并发垃圾收集器进行比较：G1、ZGC、Shenandoah 和 LXR。G1 和 LXR 采用 STW（Stop-The-World）方式迁移对象，这有助于提高应用吞吐量。然而，它们的 STW 停顿可能导致应用延迟恶化，尤其是当存活数据规模增大时。ZGC 和 Shenandoah 均采用并发方式迁移对象，因此对应用吞吐量的干扰更大。所有收集器均在 OpenJDK-11.0 环境下进行评估。由于 G1 允许用户通过设置软性限制（-XX:MaxGCPauseMillis）来控制停顿时间，我们除了默认设置 $(200\mathrm{ms})$$(200\mathrm{ms})$(200ms)(200 \mathrm{~ms}) 外，还手动将其设为 10 毫秒以获得更好的应用延迟。我们还评估了 ZGC 和 Shenandoah 的分代版本（即 GenZ 和 GenShen），由于它们未向后移植到旧版本，相应版本分别为 OpenJDK21 和 OpenJDK-22 ${}^1$${}^1$^(1){ }^{1} 。由于 GenZ 和 GenShen 在不同 JDK 版本中实现，评估结果会受到 GC 之外其他因素（如 JIT 优化效率）的影响。 LXR 基于其最新提交构建（mmtk-core 和 mmtk-openjdk 的提交号分别为 4ab99bb 和 cdbc8de），该版本同样基于 OpenJDK11.0（提交号 7caf8f7）。同时启用了 mmtk/opt cargo 特性以避免性能问题。未包含 C4 是因为其采用了与 GenZ 相似的算法但 JDK 实现差异较大（Azul JDK）。

5.2 Specjbb2015  5.2 Specjbb2015 性能测试

As shown in Table 3, Jade has worse max-jops compared with the default setting of G1 (3.98% smaller in arithmetic mean) and LXR ( $6.81\mathrm{\%}$$6.81\mathrm{\%}$6.81%6.81 \% ), but the result is much better than other concurrent copying collectors. Meanwhile, its criticaljops score of $\mathfrak{J}\mathfrak{a}\mathfrak{d}\mathfrak{e}$$\mathfrak{J}\mathfrak{a}\mathfrak{d}\mathfrak{e}$Jade\mathfrak{J a d e} is the best for all settings. The evaluation suggests that the critical-jops score of other concurrent collectors is significantly restricted by their maximum throughput, especially under tight heap configurations. As for G1, although setting a smaller soft limit ( 10 ms ) helps improve the critical-jops score, the max-jops is significantly decreased due to more frequent collections and larger overhead.
如表 3 所示，与 G1 默认设置（算术平均值低 3.98%）和 LXR（ $6.81\mathrm{\%}$$6.81\mathrm{\%}$6.81%6.81 \% ）相比，Jade 的 max-jops 表现稍逊，但远优于其他并发复制收集器。同时，其 $\mathfrak{J}\mathfrak{a}\mathfrak{d}\mathfrak{e}$$\mathfrak{J}\mathfrak{a}\mathfrak{d}\mathfrak{e}$Jade\mathfrak{J a d e} 的 criticaljops 得分在所有配置中最佳。评估表明其他并发收集器的 critical-jops 得分受限于其最大吞吐量，尤其在紧凑堆配置下更为明显。对于 G1 而言，虽然设置较小的软限制（10 毫秒）有助于提升 critical-jops 得分，但由于更频繁的垃圾回收和更大开销，max-jops 会显著下降。

5.3 HBase

5.4 Shop  5.4 在线商店服务评估

We also collect the average CPU utilization during application execution. The results in Figure 6b show that the CPU utilization under moderate throughput is similar among all collectors except ZGC. However, when the throughput is close to the maximum, both Shenandoah and ZGC’s CPU utilization quickly increases. As analyzed before, they introduce long pre-reclamation cycles, which consume much
我们同时采集了应用执行期间的平均 CPU 利用率。图 6b 显示，除 ZGC 外，各收集器在中等吞吐量下的 CPU 利用率相近。但当吞吐量接近峰值时，Shenandoah 和 ZGC 的 CPU 利用率会急剧攀升。如前文分析，这是由于它们执行耗时较长的预回收周期所致，这些周期会消耗大量

Figure 5. P99 latency results under various throughput settings in HBase.
图 5. HBase 在不同吞吐量设置下的 P99 延迟结果
more CPU resources and put heavier burdens on mutators. Meanwhile, the p99 latency of fade is relatively stable even when the CPU utilization reaches $85.78\mathrm{\%}$$85.78\mathrm{\%}$85.78%85.78 \% (QPS is 350 ), which confirms that Jade can retain high GC efficiency and short pauses even under heavy CPU-intensive workloads.
更多 CPU 资源会给 mutator 带来更重的负担。同时，即使 CPU 利用率达到 $85.78\mathrm{\%}$$85.78\mathrm{\%}$85.78%85.78 \% (QPS 为 350)时，fade 的 p99 延迟仍保持相对稳定，这证实了 Jade 即使在繁重的 CPU 密集型工作负载下也能保持较高的 GC 效率和短暂停顿。

5.5 DaCapo

5.6 Breakdown analysis  5.6 分解分析

Figure 7. P99 latency results under various throughput and workload settings in H2-throttle.
图 7. H2-throttle 场景下不同吞吐量和工作负载设置时的 P99 延迟结果。

6 Related work  6 相关工作

6.1 Concurrent collectors
6.1 并发收集器

6.2 Reference counting  6.2 引用计数

6.3 GC optimizations  6.3 垃圾回收优化

7 Conclusion  7 结论

Acknowledgments  致谢

References  参考文献