简介
在mark_phase阶段之后，所有对象都被标记为有用/垃圾对象。此时，垃圾回收器已经拥有启动垃圾回收的所有前置准备工作。
这个时候，垃圾回收期应该执行"清除回收"还是"压缩回收"呢？只有做一下试验才能得出理论支撑。
模拟压缩
这里会有一个悖论，如果你要知道压缩是否划得来，那你就得先压缩后查看其结果，才知道压缩的成本。
CLR团队如何解决这个问题呢？plan_phase阶段会计算与压缩过程相关的所有信息，而这些信息是以旁敲侧击的方式计算，并没有实际移动对象。这样我们就能从侧面知道压缩的结果
插头(plug)/间隙(gap)
模拟压缩阶段，CLR会将托管堆上的对象分为有空(plug)和没用(gap)两块，也就是所谓的插头和间隙.
通过将托管堆拆分成plug与gap，我们可以轻松计算出其重要信息
- 每个gap的大小和位置都会被记住,如果最终是清除回收，那么大多数gap都将成为Free的可用空间。
- 每个plug的位置与偏移量都会被记住，如果最终选择了压缩回收，则会使用重定位偏移量来移动plug
重排plug
计划阶段在重排 Plug 区块时，内部使用了一个单独分配器，所以此时plug是并没有被移动的.分配器仅将对象指针进行操作，进行模拟。
- 当遇到第一个plug时，分配器会找到根据对象自身的alloc_ptr指针，移动分配器的指针，并记录两个指针之间的偏移量，记为重定位偏移量
- 遇到下一个plug时，分配器会在上一个分配的基础上，继续分配。直到遇到最后一个plug。
这样，所有的重定位偏移量都被计算出来，因此GC可以准确的知道以下信息
- 压缩效率是多少？
- 如果是清除压缩，在哪里创建Free列表？
- 如果是压缩回收，plug如何移动？
plug数据结构
既然要模拟压缩，那么就意味着有数据结构来承载额外的信息。在 coreclr 源码中有一个叫 gap_reloc_pair 结构体记录Plug的信息。
gap没有专用的数据结构来存，大家可以思考一下。为什么？
- gap
记录着plug前面gap大小 - reloc
plug 新地址的相对旧地址的偏移量 - 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