并发编程网 - ifeve.com

作者： Roman Kennke

创建时间：2016/08/06 08:45

更新时间：2018/04/09 12:37

类型： 特性

状态： 已关闭/已提交

组件：hotspot/gc

范围：实现类

讨论： openjdk.java.net上的hotspot-gc-dev

影响：L

持续时间：M

优先级：4

审阅人：Aleksey Shipilev, Erik Helin, Erik Österlund, Mikael Vidstedt, Per Liden

支持者：Mikael Vidstedt

版本：10

问题讨论：8163329

属于： JEP 333: ZGC: A Scalable Low-Latency Garbage Collector

相关：JEP 318: Epsilon: A No-Op Garbage Collector

 

总结

通过引入一套纯净的垃圾收集器接口来将不同垃圾收集器的源代码分隔开。

提案目的

• HotSpot内部GC代码更好的模块化
• 在不改变以前代码的基础上使得增加一个新的GC到HotSpot VM更简单。
• 从JDK内建的代码中删除GC也更方便了。

非提案目的

• 不是增加或删除一个GC
• 这个工作将进一步改善HotSpot中GC算法的构建隔离，但并不会完成构建隔离(这属于另一个提案了)

成功指标

• 如果GC源代码的实现包含在各自的src/hotspot/share/gc/$NAME目录或者src/hotspot/cpu/share/gc/$NAME目录下就可以认为这次改动成功。这些目录下的最小化外部代码应该包含这些目录下的内部文件并且GC特定的if-else分支应该会变得非常少。
• 这次重构并不会导致性能降低。

动机

现在每个垃圾收集器的实现都是由他们内部src/hotspot/share/gc/$NAME目录源文件组成，例如G1收集器的实现在src/hotspot/share/gc/g1目录里，CMS收集器在src/hotspot/share/gc/cms目录里等等，然而，有一些零碎的东西分布在HotSpot的源码里面，比如说，大部分的GC都需要一定的障碍(栅栏)，这个实现需要在运行时、解释器、C1和C2中才能完成，这些屏障(栅栏)不包含在GC指定的目录下，而是在共享解释器、C1和C2源代码中实现(通常嵌套在冗长的if-else链中)。同样的问题也适用于诸如MemoryMXBean之类的诊断代码。这种源代码结构有以下几个缺点：

1. 对于GC的开发者来说，实现一个新的垃圾收集器需要了解所有这些地方的知识，以及如何将它们扩展到特定的需求。
2. 对于非GC部分的HotSpot开发者来说，找某个GC特定块的代码是很难的。
3. 在构建时很难排除指定的垃圾收集器，#define INCLUDE_ALL_GCS一直是构建JVM的一种方式，但只内置了Serial收集器(译者注：这里不好翻译)，但是这个机制变得过于僵化。

一个纯净的GC接口将会使实现一个新的垃圾收集器变得更简单，它将会使这个代码结构变得更规范，而且在JVM构建时可以更简单的排除一个或多个垃圾收集器。当增加一个新的垃圾收集器时，重要的事不是指出代码改变部分在HotSpot源码中的位置，而是写好一个好的接口文档说明。

提案描述

这个新的GC接口也会通过CollectedHeap这个类来定义，这个类是每个垃圾收集器需要实现的。这个CollectedHeap类是负责驱动HotSpot的垃圾收集器和剩余部分的多层面交互(有几个实用程序类需要在CollectedHeap之前被实例化 )。具体地说，一个垃圾收集器的实现需要提供以下方面的内容:

• CollectedHeap的子类
• BarrierSet集合类的子类实现，它实现了在运行时各种各样的屏障功能。
• CollectorPolicy类的实现
• GCInterpreterSupport的实现，它在GC的解释器功能中提供了各种各样的栅栏实现(使用汇编指令)。
• GCC1Support的实现， 它在GC的C1编译阶段是多种屏障(栅栏)功能的实现。
• GCC2Support的实现， 它在GC的C2编译阶段是多种屏障(栅栏)功能的实现。
• 最终GC指定参数的初始化
• 配置一个MemoryService，配置相关的内存池没内存管理等等

多个垃圾收集器之间共享的部分代码应该存在于一个helper类中，这样就可以方便的被其他的GC实现类使用，比如说，如果存在一个helper类为牌桌(译者注：原文card table)实现了多种barrier，然后任何需要牌桌上post-barrier功能的GC只需调用helper类中相应的方法即可。这种方法提供了一种灵活的方式实现新barriers，同时允许用混搭的风格去重用已有的代码。

替代选择

一个可替代的选择是继续使用现有的结构，这样做可以使用的更长久，但是会影响未来的新GC算法的发展和旧GC算法的移除。

测试

因为这只是一个纯粹的代码结构型重构，所以以前能正常运行的代码重构后也需要能正常运行，并且性能不会有所损失，这里只需运行基本的回归测试就足够了，不需要新开发新的测试用例。

风险和假设

因为这次就是HotSpot内部代码的重构，所以风险会非常低。然而通过引入额外的虚拟调用依然可能出现性能下降的风险，可以通过持续性的性能测试去降低这种风险。

依赖性

这个JEP提案将帮助 JEP291: 移除CMS垃圾收集器的实现，应为它提供了一个隔离方案，在需要的情况下允许其它人去维护它。

这个JEP也会帮助JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector的实现，并且使得它具有更低的侵入性。