标签：数据信息 不为 汇编代码 结果 spl 大页 内存地址 view global
注1：本文翻译自这篇文章
注2: 我有了新的独立博客地址，欢迎访问
ZGC是最近由Oracle为OpenJDK开源的新垃圾收集器。它主要由Per Liden编写。ZGC类似于Shenandoah或Azul的C4，专注于减少暂停时间的同时仍然压缩堆 。
虽然我不会在这里给出完整的介绍，但“压缩堆”只是意味着将仍然存活的对象移动到堆的其他区域.这样做有助于减少碎片，但通常这也意味着整个应用程序（包括其所有线程）需要暂停,这通常被称为Stop the world 。只有GC完成后，才能恢复应用程序。
在GC相关的文献中，应用程序通常称为mutator ，因为从GC的角度来看，应用程序会改变堆(mutates the heap)。根据堆的大小，这样的暂停可能需要几秒钟，这对于交互式应用程序来说可能是难以接受的。
有几种方法可以减少暂停时间：
如前所述，ZGC会进行并发压缩，这当然不是一个简单的实现功能，因此我想描述一下这是如何工作的。为什么这很复杂？
你需要将对象复制到另一个内存地址，同时另一个线程仍然可以读写旧对象。
如果对象已经复制成功，那么堆中仍有许多指向旧地址的引用需要更新到新地址。
虽然并发压缩（concurrent compaction）似乎是上述方案中降低暂停时间的最佳解决方案，但肯定会涉及一些权衡。因此，如果您不关心暂停时间，那么最好使用专注于吞吐量的GC。
理解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这样的基本类型是不需要屏障的.
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个不同的地址 ：
因此，ZGC从地址4TB开始保留16TB的地址空间（但实际上并未使用所有这些内存）。如下图：
+--------------------------------+ 0x0000140000000000 (20TB)
| Remapped View |
+--------------------------------+ 0x0000100000000000 (16TB)
| (Reserved, but unused) |
+--------------------------------+ 0x00000c0000000000 (12TB)
| Marked1 View |
+--------------------------------+ 0x0000080000000000 (8TB)
| Marked0 View |
+--------------------------------+ 0x0000040000000000 (4TB)在任何时间点，只使用这三个视图中的一个。调试时可以取消映射（unmapped）未使用的视图来验证正确性。
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）
垃圾回收主要分为两个阶段：标记和重新安置（实际上不止这两个阶段，你可以查阅源码）。
[译注：重新安置（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)
从堆中读取引用时，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中 ，这样在后面的执行过程中我们就已经加载了正确的引用。
由于每个引用都需要标记或重新安置，因此在开始标记或重新安置阶段后，吞吐量可能会立即降低。当大多数引用被修复时，这应该会变得更快。
ZGC并没有彻底摆脱STW。收集器在开始标记,结束标记和开始重新安置时需要暂停。但这种暂停通常很短,只有几毫秒。
当开始标记时，ZGC遍历所有线程堆栈以标记root set。root set是遍历对象图的开始的地方。root set通常由本地和全局变量组成，但也包括其他内部VM结构（例如JNI句柄）。
结束标记阶段时需要再次暂停。在此暂停中，GC需要清空并遍历所有线程局部标记缓冲区。由于GC可能会发现一个未标记的大型子图，因此可能需要更长时间。ZGC试图通过在1毫秒后停止标记阶段的结束来避免这种情况。它返回到并发标记阶段，直到遍历整个对象图，然后可以再次开始结束标记阶段
启动重新安置阶段会再次暂停应用程序。此阶段与开始标记非常相似，不同之处在于此阶段重新安置Root Set中的对象。
我希望我能简单介绍一下ZGC。我当然无法在一篇博客文章中描述有关此GC的所有细节。如果您需要更多信息，ZGC是开源的因此可以研究整个实现。
标签：数据信息 不为 汇编代码 结果 spl 大页 内存地址 view global
原文地址：https://www.cnblogs.com/ctgulong/p/9742434.html
