Heapothesys问世 — 具有可预测分配速率的开源 Java GC 延迟基准

Amazon Corretto 团队推出了开源 Heapothesys 基准。这是一项综合工作负载，它模拟了影响垃圾收集器 (GC) 延迟的基本应用程序特征。这一基准能创建并测试按照对象分配速率、堆占用和 JVM 旗标定义的 GC 负载情景，然后报告由此产生的 JVM 暂停。OpenJDK 开发人员由此可以创建引用点，研究其正在实现的各项技术的性能边界。

我们正致力于强化 Heapothesys ，以便更好地为更多应用程序行为建模并进行预测 (问题-12)，例如，与应用程序共享可用 CPU 电源、碎片化效应、更加动态而丰富的对象统计，以及操作系统调度表现。我们想要共同合作研究今后的步骤。我们追踪 问题清单中的想法。

Heapothesys 目前模拟的应用程序行为是按照自己的方式进行严格专业细分的，但它也经过了刻意简化，以便提供关于用户预期的边界案例。我们的目的是大致了解在连接某些基本压力因素的情况下，收集器执行情况有何不同，以及收集器在进行收缩时的余地。经过谨慎的乐观估计，这项设置能够提供垃圾收集器的选择，以及对应用程序负载预测和延迟预期的调整选项。

Heapothesys 侧重于对收集器压力负有直接责任的下列两个主要因素，具体做法是提高必须采取行动的紧迫性，从而在研究 GC 行为时发挥重要作用：

• Java 堆对象分配速率。受 Heapothesys 命令行参数控制 -a (<allocation rate in MB per second， 默认值： 1024)。
• Java 堆占用 (即存活对象的总大小，由 GC 期间对象图像扫描决定)。持久存活对象的预定数量可通过 Heapothesys 命令行参数 -h (<heap occupancy in MB，默认值：64) 设置。

了解结果

下图显示了使用这两个参数的一系列 Heapothesys 测试运行产生的停顿时间数据。我们用 jHiccup 来测量不同工作负载配置的 JVM 停顿。纵轴为对数尺度，它表示以毫秒为单位的停顿时间。请注意，停顿时间随着堆占用率 (横轴) 和分配速率 (蓝色、灰色和橙色线条) 的提高而增加。

该图表明，几乎存满的堆导致的最终结果是停顿时间更长。每种垃圾收集算法都具有不同特征，Heapothesys 能帮助我们研究并了解这些行为。在这里，我们还能看到对已经测量的收集器高分配速率的非线性反应。

如果要求高分配速率，JVM 可能无法完全履行这些要求，尤其是当正在运行的并发垃圾收集器堆占用率很高的情况下。因此，在每次运行结束时，Heapothesys 都会打印出其尽力实现的 实际 分配速率，这样我们就能看出 JVM 在哪些点上无法满足所要求的分配速率。对于具体的 JVM 配置，下表显示，当堆占用率达到80%时，实际分配吞吐量开始下降，分配速率为16 GB/s ，当堆占用率达到90%时，分配速率为4 GB/s。

致谢

Heapothesys 尽管是从零编写的，但它沿用了吉尔·泰恩关于 HeapFragger 工作负载的基本理念。HeapFragger 拥有其他特征 (例如，导致碎片化和检测分代提升)，而Heapothesys 则侧重于精确预测由此产生的分配速率。我们还要感谢吉尔在 HeapFragger 方面所做的工作以及他创建的 jHiccup 代理，我们使用该代理来测量 JVM 停顿。

许可证

Heapothesys 使用 Apache 2.0 许可证。我们欢迎您在https://github.com/corretto/heapothesys上留下您的拉取请求、错误报告、建议和反馈意见。