.NET Core GC计划阶段(plan_phase)底层原理浅谈

简介

在mark_phase阶段之后，所有对象都被标记为有用/垃圾对象。此时，垃圾回收器已经拥有启动垃圾回收的所有前置准备工作。

这个时候，垃圾回收期应该执行"清除回收"还是"压缩回收"呢？只有做一下试验才能得出理论支撑。

模拟压缩

这里会有一个悖论，如果你要知道压缩是否划得来，那你就得先压缩后查看其结果，才知道压缩的成本。

CLR团队如何解决这个问题呢？plan_phase阶段会计算与压缩过程相关的所有信息，而这些信息是以旁敲侧击的方式计算，并没有实际移动对象。这样我们就能从侧面知道压缩的结果

插头(plug)/间隙(gap)

模拟压缩阶段，CLR会将托管堆上的对象分为有空(plug)和没用(gap)两块，也就是所谓的插头和间隙.

通过将托管堆拆分成plug与gap，我们可以轻松计算出其重要信息

1. 每个gap的大小和位置都会被记住,如果最终是清除回收，那么大多数gap都将成为Free的可用空间。
2. 每个plug的位置与偏移量都会被记住，如果最终选择了压缩回收，则会使用重定位偏移量来移动plug

重排plug

计划阶段在重排 Plug 区块时，内部使用了一个单独分配器，所以此时plug是并没有被移动的.分配器仅将对象指针进行操作，进行模拟。

1. 当遇到第一个plug时，分配器会找到根据对象自身的alloc_ptr指针，移动分配器的指针，并记录两个指针之间的偏移量，记为重定位偏移量
2. 遇到下一个plug时，分配器会在上一个分配的基础上，继续分配。直到遇到最后一个plug。

这样，所有的重定位偏移量都被计算出来，因此GC可以准确的知道以下信息

1. 压缩效率是多少？
2. 如果是清除压缩，在哪里创建Free列表？
3. 如果是压缩回收，plug如何移动？

plug数据结构

既然要模拟压缩，那么就意味着有数据结构来承载额外的信息。在 coreclr 源码中有一个叫 gap_reloc_pair 结构体记录Plug的信息。

gap没有专用的数据结构来存，大家可以思考一下。为什么？

1. gap
   
   记录着plug前面gap大小
2. reloc
   
   plug 新地址的相对旧地址的偏移量
3. m_pair
   
   记录plug左右plug的位置(二叉排序树)

gap_reloc_pair的存储

按照常规方案，gap_reloc_pair的存储会在托管堆上单独开辟一段内存区间来存放，但是CLR团队非常巧妙的把gap_reloc_pair放在gap块中，因为gap不再使用，覆盖它是安全的，非常巧妙的设计！

将plug的信息存储在plug之前，这就是为什么即使是一个空对象也必须是24字节的原因

有人可能会问了，内存段的段首，第一个plug前面没有gap怎么办？

实际上，每一代的对象，都是从一个空对象开始的，因此即使是第一个插头，它也是有gap的。

眼见为实：plug前面的gap中存放着gap_reloc_pair

在bp coreclr!WKS::gc_heap::decide_on_compacting 下断点。

眼见为实：第一个plug，有一个天然的gap

代降级

因为pinned对象的存在，导致对象代的提升不是100%的，有可能会不升反降。在执行压缩的场景下，如果pinned对象出现在了一些特别尴尬的位置，GC会考虑给某些pinned对象降代或者不升代

举个例子，如果不存在降代现在，GC堆会发生什么情况

可以看到，0代段被压缩到很小，导致没分配几次内存又要GC，又会导致STW非常频繁，从而使得程序卡顿，CPU增高，吞吐量降低等现在

这个时候，只有选择不升代，或者降代，才能维持好GC代之间的平衡。

降级是一种优化，确保更多的内存碎片被重用。

眼见为实

未GC前，pinned为0代，正常情况下，它会升为1代。

因为该pinned对象非常尴尬的出现在了一大批gap对象之后，如果升代，会导致前面这一片gap对象空间同样被纳入1代的代边界范围，这极大的缩小了0代的代边界。

因此，ClR选择将Pinned对象不升代

番外篇：无效结构的内存转储

有时候，我们在plan_phase阶段，通过!dumpheap 指令查看托管堆的时候，会发现托管堆看不了。提示如下信息

还记得之前说过的gap_reloc_pair数据结构吗？它被CLR团队非常巧妙的放在了gap中。

问题就在于此，如果你的dump正好在plan_phase执行过程中，因为gap上的原始内容被gap_reloc_pair覆盖，所以此时的托管堆相当于是被破坏状态。因此CLR为了防止你被脏数据误解，直接不让你观察。

决定压缩的诱因

在模拟压缩阶段，GC根据会计算出压碎率，碎片大小的，并辅助其它条件。来决定是否执行压缩回收。

其它条件可能是，主动触发，也可能是OOM之前的最后一次Full GC ,或者是临时段空间不足

其核心方法为

BOOL gc_heap::decide_on_compacting (int condemned_gen_number,
                                    size_t fragmentation,
                                    BOOL& should_expand)

通过返回Bool，来告诉下一阶段应该执行清除回收还是压缩回收

眼见为实

https://github.com/dotnet/runtime/blob/main/src/coreclr/gc/gc.cpp