GC in C++

最新推荐文章于 2024-08-09 14:49:38 发布

大隐隐于野

最新推荐文章于 2024-08-09 14:49:38 发布

阅读量744

点赞数

CC 4.0 BY-SA版权

分类专栏： # C/C++编程语言

本文链接：https://blog.csdn.net/weixin_43778179/article/details/104671942

C/C++编程语言专栏收录该内容

151 篇文章

订阅专栏

前段时间看了一些关于GC的论文、书和源码。源码指的是Boehm的保守GC ，论文也主要是围绕这个GC相关的算法，另外还包括一些survey和性能分析的论文。而其他关于GC的一些东西主要是从其他两本书上看来，一本是谢之易老大翻译的垃圾收集，目前唯一一本关于GC算法的书，还有就是仔细阅读了C# via CLR 中关于.net GC的部分。原本想做个GC算法上的总结，但前几天在实验室做了个关于GC in C++的介绍，发现其他的一些关于GC的基本问题比算法更需要好好分析。

关于GC in C++，g9老大已经做了一篇漂亮的概述。我想做的就是按我的逻辑做一下梳理，欢迎大家抄板砖，^_^。

第一个问题，为什么我们需要GC？

或者说，在C++中，GC能给我们带来什么。很多的时候，一说起GC，就陷入一场关于性能的讨论。诚然，食堂卖饭mm（or JJ, or 阿姨, or 大妈, or 婆婆...）的pp程度对胃口有很大影响，但对于一个身心正常（if 花痴 or 别用用心者 then throw btException）且饥肠辘辘的人来说，优先考虑的肯定是口味和性价比。对于GC in C++来说，等同于口味和价格的应该是以下因素：

1. 比人肉管理更简单、安全。对于人肉内存管理Meyers对其不安全性有了很多的描述，通常一个大的人肉C++程序，没有资源泄露应该是不可能的吧。而C++的new/delete模式，对于很多非C++程序员来说还是非常复杂的。如果你做的是一个二次开发平台，未来的开发人员很多都是非C++程序员，逼着人家了解如此这般的内存管理模式，是不人道的，也是不安全。而如果是一个全GC的程序，安全（前提是GC器是安全的...）和易用都是手到擒来的。

2. 可理解性更好。在人肉C++中，咱都需要付出大量的精力去检查和编写内存管理部分，new和delete混杂在代码当中，稍有不慎，调你个半身不遂。特别是类似于A * GetA()这样的接口（delete or not），没有文档的帮助，几乎是不可理解的（而文档常常又跟不上要求）。而在GC的程序中，代码更为清晰，接口也不会存在puzzle。

所以，在你决定是否使用GC之前，先考虑一下，你是否有以上两点需求。如果你正撑的半死或者对ppmm的渴望超过了一切，那么忘了它吧，GC不是你碗里的菜。如果，OK，这正是你所需要的。那么接下来考虑的才是GC这盘味道不错的菜是否也秀色可餐、才貌双全呢？是否有其他类似的菜也让我蠢蠢欲动了。换成地球人的语言就是说，GC的效率、可兼容性等等其他方面如何？有没有其他的方案，也满足上面两点需求，并且在其他方面也表现不凡？

第二个问题，我们为什么害怕GC？

拒绝GC的理由，往往不是以上两个原因。之所以要详细的说上面那些，是因为很多人在考虑下面的问题的时候，经常忘记了上面这些巨大的好处（Maybe...include me），而掉进了某个井中痴痴的望着天空。恩...这样的井应该包括以下这些：

1. GC的效率低下

2. GC的内存占用率高

3. Stop-the-world的工作模式很可怕

4. 把内存管理这样的大事交给GC不安全

5. 无法与人肉管理的代码兼容

6. 内存回收不够及时

7. 其他我不知道的... （排名不分先后^_^）

这些都是人们害怕，或拒绝使用GC的原因。如果考虑一个最最简单的GC模型，可能以上这些问题都存在。但是，GC已经被研究了N多年，光GC in C++都被研究超过了20年。三日不见，当刮目相看，何况是如此多年，女大也该十八变了。

首要需要解决的问题应该就是分配效率。GC的分配性能一般都考量分摊性能，通常基于追踪的垃圾收集算法，都会是分配快回收慢。基于缩并的（即可移动的一种）内存分配，比如.net的GC分配都是常量级的损耗，而基于非移动的，由于有冗余，一般也不会慢。关键在于事后追踪的时间会比较长。在Boehm 的GC中，很多的算法都是出于提高标记效率，这种提高不只是从算法复杂度上考虑（代龄可以看成是优化标记复杂度的做法），更多的是从缺页率和cache miss率上来提高。在92年zorn对Boehm GC做的一篇评测中可以看到（现在的GC在分配效率、丢页率和cache miss率上都应该会有更好的表现，但找不到相关paper×_×），哪怕保守GC分配效率也是非常出色的了。而云风前辈在网易游戏中的GC应用，可以看成是特定GC的设计之道（不能做通用库用，但实现简单），我相信这会有更好的效率表现。特别是随着多核的普及，基于并发的GC 算法效率更是出类拔萃。所以，分配效率（当然，只能说在大部分的应用场合）不会成为拒绝的理由。

但我想内存占用率会成为一个问题（2、6其实是差不多的问题，占用率高主要就是预分配和延交还）。从zorn的那篇评测可以看到，Beohm GC在内存占用率方面是一般人肉分配器的一倍左右。其实，仔细思考一下GC的原理就可以理解，没有内存的冗余，几乎做不成GC的（分配一次起一次GC，还算GC么？），当然操作系统有时也作冗余（查找表），但应该会比GC做的保守的多。尽管如此，但我觉得如此大的内存占用率是和Boehm GC的分配器相关，由于是用的Mark-Sweep（标记清扫，非移动的GC算法）算法，可能会出现内存空洞（一大块内存被少量真实使用内存占据，其他部分不能被不等大的对象使用），并且由于是对齐到2^n的边界再分配，这里就可能会有约为50%的内存损失。因此，我想如果改善该内存分配器（我们有必要做内存分配器吗？当然，因为我们在托管堆上分配，操作系统已有的分配器再好，对我们也没有帮助），应该有一定的内存占用率降低。并且，如果采用的是Mark -Compact（标记缩并算法，比如.net GC）不会有对齐的损失，冗余的内存块可以更好满足虚拟内存的模式（不用的放一起，用的放一起），这样应该也会降低内存占用率。

Stop-the-world是大部分主流GC都会出现的情况（对，基于计数的GC不会有这个问题，但是...），在某些场合（高交互性？）可能会成为一个大问题。个人觉得这也是一个不可避免的问题，就像你不可能用跑一百米的速度跑1w一样（你100m跑2'？OK...算我没说）。但是，大牛们做了很多工作来降低这种停顿。在Boehm GC中，就有延迟清扫、并行、代龄等手段。而.net GC更把一次GC启动的停顿的目标设在1ms，也就是一个缺页的损失，不知道实测的情况是否能达到。如果能的话，我想大部分情况都可以忍受了吧。

内存交给GC安全么？恩，在C++中这是个问题。因为C++在运行期无法进行类型的识别，就这一条害得N多大牛一碗一碗的吐血的问题。Boehm为此可以说是无招不用，但无论如何，在理论上都不可能杜绝GC犯错的可能（除非有程序员的帮助^_^）。但我想，这年头，最不安全的还是人本身吧*_^。

兼容性的问题。恩...一个大问题。先举个例子（It's real...）。在项目中，有一部分内存是人肉分配，有另一部分是GC分配。当栈中一个非GC对象指向堆中一个非GC对象时，这个堆对象不会被扫描（因为栈中对象所指地址GC不可识别），如果这个堆对象指向另外一个托管堆中的GC对象（并且没有别人再引用），这个对象不会被Mark，也就是说GC起来会把它给收了，这就导致可怕的结果（当...程序Game over了）。为了避免这种情况，最好的办法是要保证所有对象并处于可追踪或可回收的状态。在源码可改的状况下，理论只要重载所有相关的分配器就可以了（包括全局的，重载的，STL的...）。但有一个问题我想不清楚，如果是多根的情况（比如一个MFC程序，所有类派生自CObject），就是可以修改源码，这个问题也不好解决（CObject的分配器可关么？请教ing...），更不提其他源码不受控的情况了（看看g9老大列举的吧...但解决之道一样，保证处于两个状态下）。

最后，我们拿另一盘可选的菜，计数指针来比较一下。俗话说，不怕不识货就怕货比货。其实把计数指针放在这做比较有点不公平，因为它不能提供GC能够提供的最基本的好处（味道有点酸酸的...），因为它易用性不足够强（指针不是人，不会自觉的穿衣服...），也会把代码搞乱。从效率上看，计数指针直接 Game Over，但从内存利用率和延迟性来看，计数指针会好一些。安全性上，计数指针还是依靠人；兼容性上，半斤对八两。So，两个东西不用拼得你死我活，你走你的阳关道我过我的独木桥就好（不过我一点多不觉得同时使用它们是一个好主意...）。

第三个问题，C++中需要GC么？

至此我们可以总结一下。应用GC的好处是可以提供更安全的、更可理解的代码，并且不需要付出太多额外的代价，内存管理也更为简单。其缺点包含，可能会有的分配性能较低，内存占用率更多，停顿依然不可完全避免，还存在一些安全隐患，不是和老C++如此亲密无间。

然后，我们需要在C++中用GC么。这分两个步骤来回答，首先我们需要C++做一些项目，这些项目不适合用其他语言来做；另外，在这些项目中我们可以忍受上述缺点，并很需要上述优点。存在这样的项目么？看一些g9老大的blog和Boehm GC的应用状况吧。

大部分时候，我们把GC的应用局限在了做内存管理上，其实GC的使用方法很多。你可以在项目的某个部分用GC管理内存，你可以用GC作泄漏检测器，甚至你可以用GC作Debugger。这样一来，C++中就更需要GC了。

第四个问题，GC进C++0x有什么好处？

看了上面的内容，这个问题基本成了废话。我们在C++中用GC怕什么？上述那些缺点吧。GC进C++0x有什么好处？它能解决上述大部分缺点（效率、安全、兼容性），因为这些缺点本不属于GC，只属于GC in C++。

第五个问题，我们需要怎样的GC进C++0x？

大致看了一遍GC的Proposes，看的出来，老大们为了GC进C++0x花了很多力气，有兴趣的自己可以查看一下。个人感觉GC进C++0x可以从三个方面来考量。一个是库，一个是编译器，一个是语法支持。

我觉得GC库是最基本的，Boehm GC算是一个标准，基于复制的库也可以考察。但如果没有任何编译器层面的调整的话，所有的GC库都还会存在上面那些问题。在编译期层面上的支持，最可能的就像云风前辈设想的那样，提供一个编译开关，当GC开启的时候，将对象变为运行时可识别类型的，这将会完成保证GC（指纯GC）的安全性，并大大提高效率（手动设置原子类也可以，但这毕竟增加了编写的负担）。如果不存在和老代码兼容，且只想搭建一个纯GC的C++程序（或库）的话，这是非常可行的（当然，会付出更多内存的代价）。

但最不理想的情况就是存在于人肉C++交互的情况，老大们想出了一堆关键字和使用方法其实都只针对这种情况（如果不存在这种情况，几乎不用提供新的关键字，且只需要扩展new和finalization相关的函数就好），当然这会在使用上带来更为复杂的情况。但是，只要你不愿意，你可以不用GC，因为一切都是可选的。

所以，我觉得目前GC进C++0x的方式还是很好的。大部分情况满足需求，如果有少量与老家伙们交互的情况已经可以应付了，再如果有更复杂的情况出现，不使用GC，这个世界就还是很原来一样了。

PS：Sutter老大说GC在C++0x的基本状况是：

Garbage collection: For C++0x, we're not going to add explicit support for garbage collection, and only intend to find ways to remove blocking issues like pointer hiding that make it difficult to add garbage collection in a C++ implementation. In particular, the scope of this feature is expected to be constrained as follows:

C++0x will include making some uses of disguised pointers #ff0000, and providing a small set of functions to exempt specific objects from this restriction and to designate pointer-free regions of memory (where these functions would have trivial implementations in a non-collected conforming implementation).
C++0x will not include explicit syntax or functions for garbage collection or related features such as finalization. These could well be considered again after C++0x ships.

你觉得呢？

文献列表：

[Boehm, 1992] A proposal for garbage collector safe C Compilation.

[a] 解释了为什么在C编译器开启优化时，保守垃圾收集为什么是不安全的。这种不安全主要来自于对指针的判定，编译器有时会采取一些极端手段来处理指针，以达到最优效率，导致指针的特征不明显。文中还提出了避免了这种不安全需要注意的内容。在实际实现的时候用到了Blacklist的技术。

[Boehm, 2002] Bounding space usage of conservative garbage collectors.

[a] 为了避免判定指针失误，保守垃圾收集器需要用很大的空间来判定指针，为了将此利用率限定在一定范围内，本文提出了弱健壮性的概念，即对指针的使用进行一定的限定从而可将利用率限定在一定范围内，作者做出了数学证明。

[Boehm, 2000] Fast Multiprocessor Memory Allocation and Garbage Collection.

[a] 对Boehm GC在多线程多处理器上的回收实现以及表现进行了详尽的分析和比较。

[Boehm, 1988] Garbage collection in an uncooperative environment.

[a] 对Boehm GC的基本算法，概念做了详尽的介绍。

[Boehm, 1993] Space Efficient Conservative Garbage Collection.

[a] 对如何进行高效的指针扫描和判定进行了分析，讨论了可能出现的指针判定错误，已经采取的策略。