State of and plans for the garbage collector

[Vladimir Panteleev]

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.

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.)

-- 
Best regards,
  Vladimir                            mailto:vladimir at thecybershadow.net