胡言乱语的垃圾收集？

Question

我想将垃圾收集语言(具体来说，它使用的是备受尊敬的Boehm libgc)与glib系列API进行接口。

glib和gobject内部使用引用计数来管理对象生存期。包装这些信息的正常方法是使用垃圾收集的对等对象，该对象保存对glib对象的引用，并且在对等点被终结时删除引用；这意味着当应用程序使用对等体时，glib对象保持活动。我以前也这样做过，但它很痛苦，也有它自己的问题(比如产生两个相同的底层对象的对等点)。

考虑到我无论如何都有垃圾收集器的所有开销，理想情况下，我想做的就是简单地关闭glib的引用计数，并将垃圾收集器用于任何事情。这将简化界面，没有尽头，并有望提高性能。

从表面上看，这看起来相当简单--将垃圾收集器终结器与glib对象终结器连接起来，并将ref和unref函数重写为noops --但是进一步的调查表明，更多的是: glib非常喜欢保留自己的分配器池，当然，我让它做的是垃圾收集器假设池中的所有东西都是活的，而且它会泄漏。

说服滑头使用libgc实际上可行吗？如果是这样的话，我还会面临什么问题呢？什么类型的glib性能影响会迫使所有分配通过libgc产品(而不是使用当前在glib中的优化分配程序)？

( glib文档确实说它应该干净地与垃圾收集器接口.)

Answer 1

不是的。

问这个问题后，我发现libgc不搜索第三方库拥有的内存作为参考。这意味着如果glib在它自己的工作区中只有对通过libgc分配的对象的引用，libgc就会收集它，然后您的程序就会崩溃。

libgc只适用于主程序拥有的对象。

Answer 2

http://mail.gnome.org/archives/gtk-devel-list/2001-February/msg00133.html是老的，但仍然相关。

学习语言绑定是如何工作的(代理对象，切换引用)可能有助于深入思考这一点。

更新:哦，从听到Boehm GC，我以为你想用GC代替g_malloc等，就像在那个旧帖子里一样。

如果您正在进行语言绑定(而不是GC‘’ing/C++)，那么是的，这是非常容易实现的。一个可以阅读的好示例是gjs (SpiderMonkey JavaScript)代码库。

基本思想是，您将有一个代理对象，它“保存”一个GObject，并且通常只有一个对GObject的引用。但是，唯一的复杂性是切换引用：http://mail.gnome.org/archives/gtk-devel-list/2005-April/msg00095.html

您必须将代理对象存储在GObject上，这样您就可以得到它(假设有人执行widget.get_parent()，那么您需要通过从C GObject中检索它，返回以前作为父对象设置的相同对象)。显然，您还必须能够从代理对象转到C对象。

Answer 3

对于未来的访问者，您可以参考本文(不是我的文章)：http://d.hatena.ne.jp/bellbind/20090630/1246362401。

它是用日语写的，但代码是可读的。

https://mail.gnome.org/archives/gtk-devel-list/2001-February/msg00133.html中提到的编译选项也可能有效，我还没有亲自测试它。

如果你遇到G_SLICE的另一个相关问题：http://www.hpl.hp.com/hosted/linux/mail-archives/gc/2011-January/004289.html。