[D-runtime] D Concurrent GC

[Sean Kelly]

On Sep 27, 2010, at 3:09 PM, Leandro Lucarella wrote:
> 
> 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.

Gotcha.

>> 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.

Only as the signal/slot support for object termination, there's no general solution.

>> 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.

Why are these cases slower?  Do collections occur more often overall?

> 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 :)

Vetting the GC will be tricky because basically no one will take the trouble to rebuild druntime with it to try it out.  I think we'll simply have to do our best to make sure it works correctly and then just switch over and wait for bug reports.  Do you have any objection to it being distributed under the Boost license?

>> 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.

There's an APPENDABLE flag now.  I'll check the diffs in the GC code to see if there's anything else.  Thanks for the reply!