CLR垃圾回收的设计

做者: Maoni Stephens (@maoni0) - 2015

附: 关于垃圾回收的信息，能够参照本文末尾资源章节里引用的垃圾回收手册一书。

组件架构

GC包含的两个组件分别是内存分配器和垃圾收集器。内存分配器负责获取更多的内存并在适当的时候触发垃圾收集。垃圾收集器回收程序中再也不使用的对象的内存。

有多种方法调用垃圾回收器，例如人工调用GC.Collect或者当终结线程在接收到表示低内存的异步通知时（调用）。

内存分配器的设计

内存分配器由执行引擎（EE）的内存分配辅助函数调用，并附上下列信息：

• 请求的大小
• 线程分配上下文
• 一个说明该对象是否可终结的标识。

GC不会区别对待不一样的对象。请经过执行引擎来获取对象的大小。

基于对象的大小，GC将其分红两类：小对象（< 85,000字节）和大对象（>= 85,000字节）。原则上，大小对象均可以一样处理，可是压缩大对象耗费更加昂贵因此GC才这样区分。

GC向内存分配器释放内存是经过内存分配上下文完成的。内存上下文的大小有分配额度定义：

• 内存分配上下文（Allocation contexts）是线程专用的堆区（heap segment）上小一点的区域。在单处理器（即一个逻辑处理器）机器上，使用单上下文，也就是第0代内存分配器上下文。
• 内存分配定额（Allocation quantum）是分配器在一个内存分配上下文中执行对象分配时要求更多内存时的分配定额。这个定额一般是8k，而托管对象的平均大小大约是35个字节，这样在一个分配额度里能够知足不少对象的分配请求。

大对象不使用分配上下文和定额。一个大对象自己就比这些小内存区域（8k的定额）大了。并且，这些区域的优势（下文讨论）直适用于小对象。大对象就直接在堆区上分配了。

分配器的设计目标以下：

• 在适当的时候触发GC： 分配器在超出分配预算（由收集器设置的一个阈值）时，或者分配器没法在堆区上分配时触发GC。后文会详细介绍分配预算和托管堆区。
• 保留对象的本地性： 在同一个堆区上分配的对象，保存它们的虚拟内存地址也是挨着的。
• 提升缓存的效率： 分配器以 分配定额 为单位分配内存，而按不是一个个对象分配。其将这些内存置零来便CPU的缓存提早作准备，由于随后立刻就有对象在这块内存中建立。分配定额一般是8k。
• 提升锁的效率： 内存分配上下文的线程关联性和定额保证有且只有一个线程写入指定的定额分配的内存。结果就是只要当前的内存分配上下文没有用光的话，对象分配是不须要加锁的。
• 内存完整性： 对于新建立的对象，GC老是将内存置零，以防止对象引用了随机的内存位置。
• 保持堆的可遍历性： 分配器保证定额的剩余内存是一个空闲对象。例如，若是定额里只剩下30个字节，而下一个要分配的对象大小是40字节，分配器为这30个字节建立一个空闲对象并申请一个新的分配定额。

内存分配 APIs

Object* GCHeap::Alloc(size_t size, DWORD flags); Object* GCHeap::Alloc(alloc_context* acontext, size_t size, DWORD flags);

上面的函数能够用来分配大对象和小对象。也有一个对象能够直接在大对象堆里分配内存：

Object* GCHeap::AllocLHeap(size_t size, DWORD flags);

收集器的设计

GC的目标

GC将极其高效利用内存和尽可能避免编写“托管代码”的程序员的人工干预做为奋斗目标。高效是指：

• GC应该足够频繁发生，以免托管堆上有大量（按比率或者绝对值）已分配的但无用的对象（垃圾），致使非必要的使用内存。
• GC应该尽可能不频繁发生，避免占有有用的CPU时间，哪怕在低内存致使的频繁GC。
• GC应该有高效产出。若是GC只回收了一小部份内存，那么GC（包括其使用的CPU周期）都是浪费的。
• 每次GC应该尽可能快。不少工做负荷要求低延迟。
• 托管代码程序员应该不须要知道GC的太多细节而能达到高效的内存使用率。
• GC应该自我调整以知足不一样的内存使用模式。

托管堆的逻辑形式

CLR GC是一个分代收集器，即对象是逻辑划分红几个代的。当第 N 代收集完毕后，剩下来的存活对象则被标识为第 N+1 代。这个过程被称做升级。也有异常状况咱们决定降级或者不升级。

小对象堆被分红3代：gen0, gen1和gen2。大对象只有一代 - gen3。gen0和gen1被称为短命代（对象存活的时间不长）。

对于小对象堆，代的数字表示它的年龄 － gen0属于最年轻的一代。这不是说gen0里全部的对象比gen1或gen2中任意一个对象年轻。后文会提到一些异常情形。收集一代是指收集这一代和全部比其年轻的代。

原则上大对象可使用跟小对象相同的办法处理，可是压缩大对象的代价很高，才区别对待。出于性能的考量，大对象只有一代并且老是跟gen2一块儿收集。gen2和gen3能够很大，可是收集短命代（gen0和gen1）的成本有限制。

内存分配是在最年轻的代发生的 － 对小对象来讲老是gen0，而对大对象来讲是gen3，由于只有一代。

托管堆的物理形式

托管堆是一系列的托管堆区。一个托管堆区是GC从操做系统那里申请的一个连续的内存区域。堆区被分红大小对象区，对应大小对象。每一个堆的堆区都链在一块儿。至少有一个小对象堆区和一个大对象堆区 － 用来为加载CLR而保留。

每一个小对象堆老是只有一个短命区，用来保存gen0和gen1代。这个堆区有可能包含gen2的对象。除了短命区之外，有可能有零个、一个或多个额外的堆区，用来做为gen2堆区并保存gen2对象。

在大对象堆上有一个或多个堆区。

堆区的使用是从低地址开始到高地址，即堆区里低地址对象的时间比高地址对象久。一样下文也有一些异常状况。

堆区能够按需申请，若是其不包含存活对象就会被删除，可是堆上初始的第一个堆区一直都在。对于每一个堆，一次申请一个堆区，这个在给小对象作垃圾回收时和建立大对象时发生。这样作有更好的性能，由于大对象只会跟gen2一块儿回收（执行起来代价更高）。

堆区按照申请的顺序连接在一块儿。链表上最后一个堆区永远是短命区。回收过的堆区（没有存活对象）会被复用而不是直接被删除，也就是变成新的短命区。堆区复用只发生在小对象堆。每当分配一个大对象，会考虑整个大对象堆。而小对象的分配只考虑短命区。

分配预算

分配预算是跟每一个代关联的逻辑概念。这是代里的一个大小限制用来在超出时触发一个GC。

预算是设置在代上基于该代对象存活率的一个属性。若是存活率高，那么预算就会大一些，这样在下一次GC的时候销毁的对象和存活的对象有一个更好的比率。

肯定回收哪一代

当触发一个GC时，GC必须决定回收哪一代。除了分配预算之外还要考虑如下几个因素：

• 代上碎片状况 － 若是代上的内存碎片很严重，那么在这个代上回收产量可能很高。
• 若是机器上内存负荷很大，那么GC会更积极的回收来产生更多的可用空间。这对避免没必要要的页面调度很重要。
• 若是短命堆区没有空间的话，GC会更积极的回收短命对象（更多的gen1回收）来避免申请一个新的堆区。

GC的流程

标注阶段

标注阶段的目标是找出全部存活的对象。

按代回收的好处是只须要考虑堆的一部分而不是每次都处理全部对象。当回收短命代时，GC只须要找到这一个代里存活的对象，这些信息由执行引擎上报。除了执行引擎可能引用对象之外，更老一代的对象也可能会引用新一代的对象。

对于GC使用卡片来标注更老的代。卡片是由JIT辅助函数在分配操做时设置的。若是JIT辅助函数看到一个对象在短命区的范围，而后设置包含卡片的字节来指示其来源位置。在收集短命区时，GC能够在看堆上设置过的卡片并依次处理卡片对应的对象便可。

计划阶段

计划阶段模拟压缩过程来决定最后的效果，若是压缩效果很好那么GC就会启动压缩，不然执行清理。

迁移阶段

若是GC决定压缩，其结果会移动对象，那么对这些对象的引用必须更新。迁移阶段须要处理全部指向所回收的代中的对象的引用。相比之下，而标注阶段只处理存活对象所以不须要考虑弱引用（weak reference）。

压缩阶段

这个阶段很直观，由于在计划阶段就已经计算对象应该移动的新地址，压缩阶段只须要将对象拷贝过去。

清理阶段

清理阶段会查看两个存活对象之间的空间。其为这些空间建立闲置对象。相邻的闲置对象会合并。它会将全部的闲置对象保存在 闲置对象列表（freelist）。

代码流程

术语:

• WKS GC: 工做站 GC.
• SRV GC: 服务器 GC

功能行为

WKS GC并关闭了并行GC

1. 用户线程用完了分配预算并触发一个GC。
2. GC调用SuspendEE来暂停托管线程。
3. GC决定回收哪一代。
4. 执行标注阶段。
5. 执行计划阶段并决定是否要执行压缩。
6. 若是要压缩则执行迁移和压缩过程。不然执行清理过程。
7. GC调用RestartEE来恢复托管线程。
8. 用户线程恢复执行。

WKS GC并打开了并行GC

这些说明了一个后台GC是如何实施的：

1. 用户线程用完了分配预算并触发一个GC。
2. GC调用SuspendEE来暂停托管线程。
3. GC决定是否须要后台GC运行。
4. 若是须要后台GC，唤醒它。后台GC线程调用RestartEE来恢复托管线程的执行。
5. 托管线程在后台GC执行的同时运行并分配内存。
6. 用户线程可能会用完分配预算并触发一个短命代GC（咱们称之为前台GC）。这个过程跟“WKS GC并关闭了并行GC”同样。
7. 后台GC再次调用SuspendEE来完成标注并调用RestartEE来在用户线程运行的同时并行执行清理阶段。
8. 后台GC处理完毕.

SVR GC并关闭了并行GC

1. 用户线程用完了分配预算并触发一个GC。
2. 服务器GC线程被唤醒冰调用SuspendEE来暂停托管线程。
3. 服务器GC线程执行GC工做(与WKS GC并关闭了并行GC同样).
4. 服务器GC线程调用RestartEE来恢复托管线程。
5. 用户线程恢复执行。

SVR GC并打开了并行GC

这个场景跟WKS GC并打开了并行GC同样，除了在服务器GC线程上没有后台GC。

物理架构

这个章节用来帮助你理解代码过程。

用户线程用完定额以后，经过try_allocate_more_space申请新定额。

try_allocate_more_space在须要触发GC时调用GarbageCollectGeneration。

假如WKS GC并关闭了并行GC，GarbageCollectGeneration在触发GC的用户线程上执行，代码过程以下：

GarbageCollectGeneration()
 {
     SuspendEE();
     garbage_collect();
     RestartEE();
 }

 garbage_collect()
 {
     generation_to_condemn();
     gc1();
 }

 gc1()
 {
     mark_phase();
     plan_phase();
 }

 plan_phase()
 {
     // actual plan phase work to decide to // compact or not if (compact) { relocate_phase(); compact_phase(); } else make_free_lists(); }

假如WKS GC并打开了并行GC（默认状况），后台GC的代码过程以下：

GarbageCollectGeneration()
 {
     SuspendEE();
     garbage_collect();
     RestartEE();
 }

 garbage_collect()
 {
     generation_to_condemn();
     // decide to do a background GC // wake up the background GC thread to do the work do_background_gc(); } do_background_gc() { init_background_gc(); start_c_gc (); //wait until restarted by the BGC. wait_to_proceed(); } bgc_thread_function() { while (1) { // wait on an event // wake up gc1(); } } gc1() { background_mark_phase(); background_sweep(); }

资料

• .NET CLR GC Implementation
• The Garbage Collection Handbook: The Art of Automatic Memory Management
• Garbage collection (Wikipedia)