State of and plans for the garbage collector

[dsimcha]

== Quote from Leandro Lucarella (luca at llucax.com.ar)'s article
> dsimcha, el 15 de julio a las 19:23 me escribiste:
> > == 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.
> Not completely, if you have a multi-core, suddenly your program becomes
> multi-threaded and uses more than 1 core. In that case, a concurrent GC
> could improve the overall performance of the application.

In theory.  I thought that in practice concurrent GC's (I'm not talking about the
case of thread-local heaps) are always slower throughput-wise than stop-the-world.