[xmlp] the recent garbage collector performance improvements

[H. S. Teoh]

On Thu, Feb 02, 2012 at 08:48:20PM -0600, Robert Jacques wrote:
[...]
> So to answer your question, yes, someone has made one of these types
> of GC for D called CDGC. No, it doesn't look like Windows will support
> this anytime soon.  And cloning GCs, don't solve the problems of large
> heaps, soft/hard realtime issues like game render threads, and it
> actually makes the embarrassingly long pause (when they happen)
> longer. Now, CDGC, as I understand it, is better written than our
> current GC and would probably improve things, but I don't see it as
> the final end goal.

To me, the final goal should be to make the GC swappable, that is,
there's a way to tell the compiler which GC you want to use.

After I got convinced about the benefits of GC by the article on garbage
collection in DPLO, I started reading up a bit about different GC
algorithms, and my conclusion is that there is no such thing as a
one-size-fits-all GC.  Every GC algo out there is sensitive to the kind
of allocations the program makes, and the memory/speed constraints
you're running under. So the real solution to GC performance problems is
to make it swappable. Today, for instance, I found a book that talks
about a hard real-time GC, which is very different from the paper I
mentioned earlier.

The point is, if you want hard real-time guarantees, it should be
possible to tell the compiler to use a GC that gives you that, and if
you're OK with soft real-time, then you can tell the compiler to use
something like CDGC. And if you're writing a batch-processing program
you can use a GC with a long STW pause but better overall throughput.

Anyway, I found the blog of the guy who implemented CDGC, and it seems
that it did quite well performance-wise at the end. Apparently it's in
an experimental D2 branch; anyone tried to use it recently?


T

-- 
Questions are the beginning of intelligence, but the fear of God is the beginning of wisdom.