State of and plans for the garbage collector

[dsimcha]

== Quote from Bane (branimir.milosavljevic at gmail.com)'s article
> Anyway, I'm here bitching myself :) Just want to say that idea to have more than
one GC type to chose when compiling would be very interesting thing, if single
implementation can't be good for all cases.
> > 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.
> >

If/when we have enough manpower to write/maintain multiple GC's, here are some GC
designs that can be either optimizations or pessimizations depending on use case:

1.  Precise heap scanning (i.e. in the absence of copying/heap compaction).  If
you allocate mostly small objects, you're probably very seldom bitten by false
pointers and the O(1) overhead per block needed to store type info may be
significant.  If you allocate mostly large objects, you've probably been eaten
alive by false pointers and the O(1) per block overhead is negligible to you.

2.  Concurrent collection.  If you use threads for concurreny/latency reasons,
this can be a boon.  If you use threads for parallelism/throughput reasons, or
write single-threaded code, this is a complete waste.

3.  Thread local allocators.  Quite simply, it's a space-speed tradeoff, and it
depends which is more important to you.