2011-02-01 95 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」集合,儘管這樣做的複雜性這是人們爲什麼通常不會的好跡象。