JDK 11 ZGC简介

jdk 11 zgc简介

注1：本文翻译自这篇
注2: 我有了新的独立博客，欢迎访问

前言

zgc是最近由oracle为openjdk开源的新垃圾收集器。它主要由per liden编写。zgc类似于shenandoah或azul的c4，专注于减少暂停时间的同时仍然压缩堆 。

虽然我不会在这里给出完整的介绍，但“压缩堆”只是意味着将仍然存活的对象移动到堆的其他区域.这样做有助于减少碎片，但通常这也意味着整个应用程序（包括其所有线程）需要暂停,这通常被称为stop the world 。只有gc完成后，才能恢复应用程序。

在gc相关的文献中，应用程序通常称为mutator ，因为从gc的角度来看，应用程序会改变堆(mutates the heap)。根据堆的大小，这样的暂停可能需要几秒钟，这对于交互式应用程序来说可能是难以接受的。

有几种方法可以减少暂停时间：

• gc可以在压缩时使用多个线程（并行压缩 parallel compaction）
• 压缩工作也可以分为多个暂停（增量压缩 incremental compaction）
• 压缩堆的同时不暂停应用程序，或者只是很短时间暂停（并发压缩 concurrent compaction）
• go的gc就是完全不压缩堆

如前所述，zgc会进行并发压缩，这当然不是一个简单的实现功能，因此我想描述一下这是如何工作的。为什么这很复杂？

你需要将对象复制到另一个内存地址，同时另一个线程仍然可以读写旧对象。

如果对象已经复制成功，那么堆中仍有许多指向旧地址的引用需要更新到新地址。

虽然并发压缩（concurrent compaction）似乎是上述方案中降低暂停时间的最佳解决方案，但肯定会涉及一些权衡。因此，如果您不关心暂停时间，那么最好使用专注于吞吐量的gc。

gc屏障 (gc barriers)

理解zgc如何进行并发压缩的关键是load barrier (通常在gc文献中称为read barrier).这里简单介绍一下，详细的描述请看下面的load barrier一节。

如果gc有读取屏障（load barrier），则在从堆读取引用时，gc需要执行一些额外操作。在java中,也就是像执行这样的代码object xxx=obj.field时需要额外操作。

对于像obj.field = value这样的操作，gc也可能需要写入屏障(叫做write barrier或者store barrier)[译注：在分代gc还有引用计数中会用到写入屏障].

这两个操作都比较特殊因为它们在每次读取或写入堆时发生的。load barrier和store barrier的名称有点令人困惑，但注意这个屏障与cpu的内存障碍是完全不同的两个概念

堆中的读取和写入都非常常见，因此两种gc屏障都需要非常高效，在常见情况下就是一些汇编代码。read barrier通常比write barrier大一个数量级（可能会因应用程序而异），因此read barrier对性能要求更高。

例如，分代gc通常只需要一个写屏障，不需要读屏障。zgc则需要一个读屏障但没有写屏障。对于并发压缩，我没有看到没有读取障碍的解决方案。

这里需要注意：即使gc需要某种类型的屏障，只有在读取或写入堆中的引用时需要它们。读取或写入像int或double这样的基本类型是不需要屏障的.

指针标记（pointer tagging or colored pointers ）

zgc在堆引用中存储额外的元数据 ，在x64上是64 bit（zgc目前不支持compressed oops和 class pointers）。64位中的48位用做x64上的虚拟内存地址 。虽然确切地说只有47位，因为第47位确定了位48-63的值（目前这些位都是0）。zgc保留对象实际地址的前42位（在源代码中称为偏移量 ）。42位地址理论上就会有4tb的堆大小限制。其余的位用于这些标志： finalizable ， remapped ， marked1和marked0 （保留一位用于将来使用）。如下图所示:

 6                 4 4 4  4 4                                             0
 3                 7 6 5  2 1                                             0
+-------------------+-+----+-----------------------------------------------+
|00000000 00000000 0|0|1111|11 11111111 11111111 11111111 11111111 11111111|
+-------------------+-+----+-----------------------------------------------+
|                   | |    |
|                   | |    * 41-0 object offset (42-bits, 4tb address space)
|                   | |
|                   | * 45-42 metadata bits (4-bits)  0001 = marked0
|                   |                                 0010 = marked1
|                   |                                 0100 = remapped
|                   |                                 1000 = finalizable
|                   |
|                   * 46-46 unused (1-bit, always zero)
|
* 63-47 fixed (17-bits, always zero)

在堆引用中具有元数据信息使得解引用更加昂贵，因为需要mask地址以获得没有元信息的真实地址。zgc采用了一个很好的技巧来避免这种情况：

当从内存中读取时，会设置marked0 , marked1或remapped中的一个。

在偏移x处分配页面（allocating a page）时，zgc将同一页面映射到3个不同的地址 ：

• for marked0 ：(0b0001 << 42) | x
• for marked1 ： (0b0010 << 42) | x
• for remapped ： (0b0100 << 42) | x

因此，zgc从地址4tb开始保留16tb的地址空间（但实际上并未使用所有这些内存）。如下图：

  +--------------------------------+ 0x0000140000000000 (20tb)
  |         remapped view          |
  +--------------------------------+ 0x0000100000000000 (16tb)
  |     (reserved, but unused)     |
  +--------------------------------+ 0x00000c0000000000 (12tb)
  |         marked1 view           |
  +--------------------------------+ 0x0000080000000000 (8tb)
  |         marked0 view           |
  +--------------------------------+ 0x0000040000000000 (4tb)

在任何时间点，只使用这三个视图中的一个。调试时可以取消映射（unmapped）未使用的视图来验证正确性。

pages & physical & virtual memory

shenandoah将堆分成大量同样大小的区域 。除了不适合单个区域的大对象外，对象通常不会跨越多个区域。大对象被分配在多个连续区域中。我非常喜欢这种方法，因为它非常简单。

在这方面，zgc与shenandoah非常相似。在zgc的说法中，区域称为页面pages 。

与shenandoah的主要区别：zgc中的页面可以有不同的大小（但在x64上总是2mb的倍数）。

zgc有3种不同的页面类型： 小型 （2mb大小）， 中型 （32mb大小）和大型 （2mb的倍数）。

在小页面中分配小对象（最大256kb大小），在中型页面中分配中型对象（最多4mb）。大页面中分配大于4mb的对象。大页面只能存储一个对象.小页面或中间页面可以分配多个。

有些令人困惑的是大页面实际上可能小于中等页面（例如，对于大小为6mb的大对象）。

zgc的另一个不错的特性是，它还可以区分物理内存和虚拟内存。这背后的想法是通常有足够的虚拟内存（zgc总是4tb），而物理内存更稀缺。物理内存可以扩展到最大堆大小（使用-xmx设置），因此这比4 tb的虚拟内存要小得多。在zgc中分配特定大小的页面意味着分配物理和虚拟内存。在zgc中，物理内存不需要是连续的，虚拟内存空间是连续的。

为什么说这是一个不错的属性？

分配连续范围的虚拟内存是很容易的，因为我们通常有足够的虚拟内存。但在物理内存中有3个大小为2mb的空闲页面的情况很普通，但是对于大型对象分配我们需要6mb的连续内存。有足够的空闲物理内存，但不幸的是这个内存是不连续的。zgc能够将这些非连续的物理页面映射到单个连续的虚拟内存空间。如果无法映射，我们就会耗尽内存（发生oom）

标记和重新安置对象（marking & relocating objects）

垃圾回收主要分为两个阶段：标记和重新安置（实际上不止这两个阶段，你可以查阅源码）。

[译注：重新安置（relocating）指的是把对象从一个内存区域移到另外一个区域，重映射(remapping)只的是把指向老的地址的引用更新到新的地址]

一次gc从标记阶段开始，标记所有可到达的对象。在这个阶段结束时，我们知道哪些对象仍然存活，哪些对象是垃圾。zgc将此信息存储在每个页面的live map中。live map是一个位图(bitmap) ，用于存储给定索引处的对象是否可达和/或最终可达（对于具有finalize method的对象而言）。

在标记阶段，应用程序线程中的load-barrier将未标记的引用推送到线程局部标记缓冲区。只要此缓冲区已满，gc线程就可以获得此缓冲区的所有权，并以递归方式遍历此缓冲区中的所有可到达对象。在应用程序线程中标记只是将引用推送到缓冲区，gc线程负责遍历对象图并更新live map.

标记阶段结束后，zgc要重新安置 relocation set中的所有活动对象。

relocation set表示一组需要被回收的页面（pages)，例如那些垃圾最多的页面。存活的对象由gc线程或应用程序线程通过读取屏障（load barrier）重新安置（relocated）（也就是放到新的地址去）.zgc为relocation set中的每个页面分配forwarding table.

forwarding table基本上是一个hash map，它存储一个对象已被重新安置到的地址（如果该对象已经被重新安置）。

zgc方法的优点是我们只需要为relocation set中的页面分配forwarding table的空间.
相比之下，shenandoah将转发指针存储在每个对象本身，这样就谁有一些额外的内存开销。

gc线程遍历 relocation set中的存活对象，并重新安置（relocate）尚未重新安置的对象。这时可能发生应用程序线程和gc线程同时重新安置（relocate）同一个对象，在这种情况下，谁先relocate谁获胜，zgc使用原子cas操作来确定胜者。

当不处于marking阶段时，load-barrier会重新安置(relocates )/重新映射(remaps )从堆加载的所有引用。这确保了mutator看到的每个新引用都已指向对象的最新副本。重新映射（remaps）对象就是在forwarding table中查找新的对象地址。

一旦gc线程完成了relocation set的处理，重新安置阶段就完成了。虽然这意味着所有对象都已重新安置，但通常仍会有引用指向relocation set，需要将其重新映射（remapped ）到新地址。这些引用会被load-barrier自我修复。如果对于这些引用的读取发生的不够快，（也就是这段时间内，应用程序没有读到这些指向relocation set的引用），这些引用会在下一次mark阶段给修复。这意味着标记阶段还需要检查 forward table以重新映射(remap) （但不重新安置 ，所有对象之前阶段都保证被重新安置）对象到它们的新地址。

这也解释了为什么对象引用中有两个标记位（marked0 和marked1 ）。标记阶段在标记的marked0和marked1位之间交替。在重新安置阶段之后，仍可能存在未重定向（remapped）的引用，所以我们需要知道上一个gc周期的情况。如果新的标记阶段使用相同的标记位，则load-barrier就知道该引用为已标记。

(译注：这里看起来像是gc周期remap和mark可以重叠，实际上确实是重叠的。如图所示：

更详细的信息可以看这个slide)

load-barrier

从堆中读取引用时，zgc需要一个所谓的load-barrier（也称为read-barrier）。每次java程序访问对象类型的字段时，我们都需要插入此load-barrier，例如obj.field 。访问某些其他原始类型的字段不需要屏障，例如obj.anint或obj.andouble 。zgc不需要obj.field = somevalue存储/写入障碍。

根据gc当前所处的阶段（存储在全局变量zglobalphase中 ），如果尚未标记或重新安置对象，则屏障会标记对象或重新安置它

全局变量zaddressgoodmask和zaddressbadmask
存储对应的掩码，该掩码确定引用是否已被认为是好的（这意味着已经标记或重新映射/重新安置remapped/relocated）或者是否仍然需要一些操作。这些变量仅在标记开始阶段和重新安置阶段同时改变.zgc源代码中的这个表格可以很好地概述这些掩码的状态：

               goodmask         badmask          weakgoodmask     weakbadmask
               --------------------------------------------------------------
marked0        001              110              101              010
marked1        010              101              110              001
remapped       100              011              100              011

屏障的汇编代码可以在macroassembler for x64中看到，我只会为这个屏障显示一些伪汇编代码：

mov rax, [r10 + some_field_offset]
test rax, [address of zaddressbadmask]
jnz load_barrier_mark_or_relocate

# otherwise reference in rax is considered good

第一个汇编指令从堆读取引用： r10存储对象引用， some_field_offset是一些字段偏移常量。加载的引用存储在rax寄存器中。

然后针对当前的坏掩码测试该引用（这只是一个位与）。此处不需要同步，因为zaddressbadmask仅在stw时才更新。如果结果不为零，我们需要执行屏障。

屏障需要根据我们当前所处的gc阶段标记或重新安置对象。在此操作之后， 他需要更新存储在r10 + some_field_offset中的引用来指向新引用。这步操作是必要的，以便来该字段的后续加载返回正确的引用。

由于我们可能需要更新引用地址，因此我们需要使用两个寄存器r10和rax作为加载的引用和对象地址。正确的引用也需要存储到寄存器rax中 ，这样在后面的执行过程中我们就已经加载了正确的引用。

由于每个引用都需要标记或重新安置，因此在开始标记或重新安置阶段后，吞吐量可能会立即降低。当大多数引用被修复时，这应该会变得更快。

stop-the-world 停顿

zgc并没有彻底摆脱stw。收集器在开始标记,结束标记和开始重新安置时需要暂停。但这种暂停通常很短,只有几毫秒。

当开始标记时，zgc遍历所有线程堆栈以标记root set。root set是遍历对象图的开始的地方。root set通常由本地和全局变量组成，但也包括其他内部vm结构（例如jni句柄）。

结束标记阶段时需要再次暂停。在此暂停中，gc需要清空并遍历所有线程局部标记缓冲区。由于gc可能会发现一个未标记的大型子图，因此可能需要更长时间。zgc试图通过在1毫秒后停止标记阶段的结束来避免这种情况。它返回到并发标记阶段，直到遍历整个对象图，然后可以再次开始结束标记阶段

启动重新安置阶段会再次暂停应用程序。此阶段与开始标记非常相似，不同之处在于此阶段重新安置root set中的对象。

结论

我希望我能简单介绍一下zgc。我当然无法在一篇博客文章中描述有关此gc的所有细节。如果您需要更多信息，zgc是的因此可以研究整个实现。