State of and plans for the garbage collector

[Bane]

If I had to chose one topic with most bitchin' on this newsgroup I have impression it would be the one about GC. They usually goes from 'GC managed programs are slow, D ain't good enough', to 'language X has better GC than D', to ' GC that D has is bad at Z'.

Why not make D summer of code - write your own GC optimized for special case of XYZ, send it, bundle all up in D with compiler switch '--useGC=XYZ'. That is only way to really compare what is best for special case.

> 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.
> 
> So, my question is this: what are the plans for the garbage collector? Is the 
> intention to continue to improve it bit by bit, to give it a major overhaul at 
> some point, to outright replace it at a later date, or something else entirely?
> 
> If D is going to compete with C and C++, it needs to be highly efficient, and if 
> the garbage collector isn't up to snuff, that's going to be a big problem. I'm 
> not looking to complain about the current garbage collector - I really don't 
> know how good or bad it is - but if it is rather poor (as I've gotten the 
> impresison that it is - at least in some respects - from various discussions on 
> it here), then I'd assume that it needs a major overhaul or replacement at some 
> point. So, are there any specific plans with regards to that, or is that just 
> something that may be considered in the future?
> 
> - Jonathan M Davis