[D-runtime] D Concurrent GC

[Leandro Lucarella]

OK, here I am again, after 13 days (and only 13 because I've just fixed
it myself) without phone and Internet connection, thanks to my friends
from TELECOM Argentina.

Sorry about the tiny rant, see the comments below for the important
stuff...

Sean Kelly, el 24 de septiembre a las 09:47 me escribiste:
> On Sep 23, 2010, at 2:14 PM, Leandro Lucarella wrote:
> > See bug 3463 (http://d.puremagic.com/issues/show_bug.cgi?id=3463),
> > it's in the patched object.d file. It should be easy to avoid the
> > precise code by hardcoding the opts.options.conservative variable to
> > true and defining PointerMap as in the patched object.d, so everything
> > is scanned conservatively (you can also remove all the code for
> > precise scanning, but I really hope it gets integrated into D sooner
> > than later).
> 
> Since you've already done the work of adding precise scanning to your
> GC, integrating the rest should be easy.  I'll take a look at the
> patch.

The main problem here is the DMD-side, you've got to convince Walter.

> How do you feel about the state of your GC right now?  Is it
> ready to be integrated with druntime, or are there still things left
> to do?

I think is ready (as in ready enough, of course there is plenty of
room for improvements still) now that I've pushed the last changes
I couldn't push before because of the connectivity problems. The main
fixed problem was the heap becoming too big with eager allocation if no
big objects were used because minimize was only called by bigAllog(),
but is fixed now.

I don't know if the weakref stuff is working either, since I have to
test programs that use them, but I don't know either if druntime have
weakrefs.

> I know some additional performance tuning may need to be done
> with your parallel collection scheme, but I'd imagine that could
> always be turned off so it behaves pretty much like the current GC?

Right now, for the only real program I tested (Dil generating the entire
Tango docs), is way faster than the basic collector (about 2 times
faster on single-core and 2.5 times faster on multi-core), other are way
faster too but some tests that are very GC centric (like the shootout
binary trees test) are a little slower, but I don't think that's a fair
test for this kind of collector.

This is talking about total run-time, the maximum pause is reduced even
much more, about 10x or more (with exceptions, but again the exceptions
are in not-very-realistic test programs).

So I think performance-wise, it deserves to be the default collector (at
least in Linux). I don't know stability-wise though :)

> I'll have to see what I've changed in the GC since creating druntime
> as well.  Nothing major I think though.

I think the array appending changes are the bigger since the last time
I checked.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Every day 21 new born babies will be given to the wrong parents