2011-02-01 96 views
16

我正在为静态类型的面向对象语言编写一个编译器。目前我正在研究要使用的垃圾收集算法。我想知道是否有一个收集器是:是否有满足这些要求的垃圾收集算法?

  • 开源和记录,以便我可以实现它。
  • Acurrate
  • 全球,即有每个进程只有一个收藏家,而不是说每个线程之一。
  • 增量式和/或并发式,以避免长时间停留在主要集合中。
  • 适合这种编程范例。一个例子是什么不会是一个收集器,在破坏性分配的情况下变得非常缓慢。

编辑:为了澄清,我在想,如果有一个可实现的算法做这个,不是,如果有一个现成的,货架收集器。

+3

如果针对.NET或Java平台都将获得一个免费的。 – 2011-02-01 13:55:34

+4

这里有一个很好的[系列文章](http://blogs.msdn.com/b/abhinaba/archive/2009/01/25/back-to-basic-series-on-dynamic-memory-management.aspx )垃圾收集。 – jason 2011-02-01 14:34:57

回答

2

(我宁愿让这个作为一个评论,但我没有足够的代表。)

如果您正在寻找算法而不是代码,我会definetely采取学术文章看看。我偶然发现OOPSLA 2003年提起诉讼,并立即我记得你的问题的---他们对垃圾收集2次会议:

http://www.oopsla.org/oopsla2003/files/pap-session-garbage-collection-1.html
http://www.oopsla.org/oopsla2003/files/pap-session-garbage-collection-2.html

那些“大爆炸”的时刻的优点开始您的研究是,您可以在任何看起来很有前途的文章上使用Google Scholar,并通过查找标题然后单击“引用者”链接查看是否有更新的后续跟踪例如:

http://scholar.google.com/scholar?cites=11437015034573374705&as_sdt=2005&sciodt=0,5&hl=en

(既然你有这么多要求,你可能有你发现你的即时收集器之前亲吻青蛙许多。)

0

你可能会从单声道,这是一个开源的.Net实现窃取垃圾回收。他们最近发布了一个新的GC引擎(我认为)符合上述所有要求。

0

像这样偷取收集器的问题:垃圾收集器通常与它们所写的语言绑定在一起。良好的功能语言收藏家倾向于采取不同于收集者的命令。开源的地方有可能是原因从偷:

  • ocaml的
  • 的Python
  • ...
0

这是(显然)很难没有一些更好的主意回答您希望托管的语言,但您看过Parrot VMPDD 9: Garbage Collection Subsystem讨论了它的GC,并且似乎击中了你所要求的流行语,以及它所设计的语言(Perl6主要是用lua和一个强类型的javascript-ish事物,称为winxed为强秒),绝对具有破坏性的赋值和对象。

它是一个VM目标,但不是独立的GC。我真的怀疑你会发现与某种虚拟机无关的现成GC(除保守收集器之外,如Boehm),因为要使它准确需要更多关于堆栈帧的信息,而不是反汇编可以提供的信息。

5

还有一种非实验性垃圾收集算法可以满足您的所有需求:简单的自动refcounting。总体而言,refcounting并没有获得足够的信用作为一个可行的选择,但实际上它在很多情况下运行得非常好,没有任何大的批量延迟,并且不需要复杂的魔法。

一个问题仍然是清理循环引用,您至少可以非常少地完成循环引用;关心速度的应用程序开发人员可以在需要删除对象时明确地打破循环。

refcounting的一个小特点是,它比其他形式的垃圾回收更具有直流兼容性。如果您正在运行一个循环,每次循环都会分配一些小的临时对象,则引用GC(或显式内存管理当然)可以每次都重用相同的内存,从而避免不必要的缓存刷新。任何其他类型的GC只会周期性地释放对象,导致更大的内存占用并因此缓慢。

对于大量多线程系统来说,重新计算并不是非常有效,因为每次触摸refcount时都需要获取锁。但是,如果您正在设计一种新语言,那么您可以通过一项巨大的事情来提高整个语言的性能和可靠性:防止几乎所有对象在线程之间共享。即。使分享明确。如果你这样做了,你会知道哪些对象是不被共享的,因此当增加/减少refcount时哪些对象需要被锁定,哪些对象可以被解锁。如果没有任何锁定,则可以非常出色地实现计数性能。

0

的阿祖尔垃圾收集器是私有的,但有可用的关于他们的算法足够的信息,你应该能够实现类似的东西:http://news.ycombinator.com/item?id=2022723

这绝对支持“pauseless”集合,尽管这样做的复杂性这是人们为什么通常不会的好迹象。