用 glib 收集垃圾？答案

【问题标题】：Garbage collection with glib?用 glib 收集垃圾？
【发布时间】：2011-06-04 23:35:22
【问题描述】：

我想将一种垃圾收集语言（具体来说，它使用古老的 Boehm libgc）连接到 glib 系列 API。

glib 和 gobject 在内部使用引用计数来管理对象的生命周期。包装这些的常规方法是使用垃圾回收的对等对象，该对象持有对 glib 对象的引用，并在对等对象完成时删除该引用；这意味着 glib 对象在应用程序使用对等点时保持活动状态。我以前做过这个，它可以工作，但是它很痛苦并且有它自己的问题（例如产生同一个底层对象的两个对等点）。

鉴于我已经获得了垃圾收集器的所有开销无论如何，理想情况下我想做的就是简单地关闭 glib 的引用计数并将垃圾收集器用于所有事情。这将无限简化界面并有望提高性能。

从表面上看，这似乎相当简单 --- 将垃圾收集器终结器连接到 glib 对象终结器，并将 ref 和 unref 函数覆盖为 noops --- 但进一步的调查表明，这不仅仅是那：例如，glib 非常喜欢保留自己的分配器池，当然我让垃圾收集器假设池中的所有内容都是活动的并且会泄漏。

说服 glib 使用 libgc 真的可行吗？如果是这样，我可能会面临哪些其他问题？什么样的 glib 性能影响会强制所有分配通过 libgc 生成（而不是使用当前在 glib 中的优化分配器）？

（glib 文档确实说它应该干净地连接到垃圾收集器...）

【问题讨论】：

标签： garbage-collection glib

【解决方案1】：

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

了解语言绑定的工作原理（代理对象、切换引用）可能有助于思考这一点。

更新：哦，从听到 Boehm GC 开始，我以为您正试图用 GC 替换 g_malloc 等，就像那个旧帖子中一样。

如果您正在执行语言绑定（不是 GC'ing C/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 对象。

【讨论】：

你有什么更新的吗？ 2001 年实际上是史前 gobject-wise。
除了添加切换参考之外，我不确定从那时起基本情况是否发生了变化。最大的变化是 2.0.0 中的 GtkObject 到 GObject
我认为这里的简短回答是 GC 在 C/C++ 中无法真正工作，因为您将无法运行终结器。但是您可以使用带有智能指针的 C++ 绑定。几年前，我设计了一个名为 Inti 的轻量级 C++ 绑定的原型，它只是智能指针（几乎只是一个头文件）而不是一个完整的包装器。
哦，我想念你正在绑定一种语言。在那种情况下，你很好。只需复制任何现有的语言绑定。
哦，好吧。我宁愿通过简单地使用垃圾收集器来收集所有东西来避免所有引用计数的废话，从而使问题消失，但听起来有太多繁琐的边缘条件使它无法可靠地工作。看来我只能使用代理了。（在与引用计数操作系统作斗争方式太多年之后，我满怀激情地厌恶它——它是对真正垃圾收集的苍白、繁琐且难以工作的模仿......）

【解决方案2】：

没有。

自从提出这个问题后，我发现 libgc 不会搜索第三方库拥有的内存以获取引用。这意味着如果 glib 在其自己的工作空间中具有对通过 libgc 分配的对象的唯一引用，libgc 将收集它，然后您的程序将崩溃。

libgc 只能安全地用于主程序拥有的对象。

【讨论】：

【解决方案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。

【讨论】：

不幸的是，g_mem_set_vtable 似乎已经过时，无需替换。