State of and plans for the garbage collector

[Robert Jacques]

On Thu, 15 Jul 2010 04:28:43 -0400, Vladimir Panteleev  
<vladimir at thecybershadow.net> wrote:

> On Thu, 15 Jul 2010 10:18:38 +0300, Jonathan M Davis  
> <jmdavisprog at gmail.com> wrote:
>
>> Okay. I really don't know much about garbage collectors, how they work,  
>> or what makes one particularly good or bad (other than the fact that it  
>> needs to be efficient execution-wise and manage memory wisely so that  
>> you don't use too much of it or do anything else that would be an  
>> overall negative for performance). However, from the comments here -  
>> both recent and in the past - it's pretty clear that D's garbage  
>> collector is fairly outdated. I would assume that that would be  
>> negative for performance - certainly it would mean that significant  
>> improvements could be made.
>
> IMO the D GC isn't bad, it's just mediocre. (It could have been way  
> worse.)
>
> I would like to use this opportunity to bring up a GC implementation  
> written by Jeremie Pelletier, which seems to have gone mostly unnoticed  
> when it was posted as a reply to D.announce:
> http://pastebin.com/f7a3b4c4a
>
> Aside from multiple optimizations across the board, this GC employs an  
> interesting different strategy. The gist of it is that it iteratively  
> destroys only objects that have no immediate references. In the case of  
> long linked lists, this trades destruction complexity with scan  
> complexity, which is a very good change - most times deeply-nested  
> structures such as linked lists survive multiple generational cycles.

Wouldn't that mean it can't handle cycles?

> Jeremie, if you're reading this: how goes your D2 runtime project?
>
> (I also have an unfinished generational GC lying around, which is still  
> unknown if it's viable performance-wise - I should really try to finish  
> it one day.)