[D-runtime] Precise garbage collection

[Leandro Lucarella]

On Wed, Aug 07, 2013 at 10:42:25PM +0200, Rainer Schuetze wrote:
> On 07.08.2013 19:12, Leandro Lucarella wrote:
> >On Fri, Jun 21, 2013 at 09:37:51PM +0200, Leandro Lucarella wrote:
> >>>Before creating a pull request, I'd like to hear opinions on whether
> >>>this should be included, if other choices would be better and where
> >>>it should be improved.
> >>
> >>I'll read this e-mail in detail next week, and hopefully I'll take a
> >>look at the code too.
> >
> >Finally I had some time to do this. I made some comments in the commit
> >themselves in GitHub.
> >
> 
> Thanks for the comments.
> 
> >Is there any reason why not to do the review with a proper pull request?
> >For some reason you prefer to keep this somehow more private for now?
> >
> 
> It currently even fails to compile the druntime unittests because of
> the reported problems with the RTInfo generation. May it is better
> to let it fail in public ;-)

:O
I didn't even try to compile it to be honest, just looked at the code,
are you saying is not really working as it is now? I'm sorry, I'm not
familiar with all the RTInfo stuff.

> I also wanted to implement a different version for comparison, that
> stores the TypeInfo pointer in the allocation. I have a first
> attempt but it is quite a bit slower as it has to do some dynamic
> casting during scanning because of the way arrays are implemented.
> Some optimizations are needed to make an unbiased comparison, but
> other stuff distracted from doing this.

The old precise scanning patch I used with the concurrent collector did
that and the overhead was considerable:
http://www.llucax.com.ar/blog/blog/post/098ceae8
(and http://www.llucax.com.ar/blog/blog/post/1490c03e also analyze the
performance but is a little confusing, I'm not sure what happened there
because what I said in the text is not really reflected in the graphs
:P).

But it would be interesting to be able to compare it with the approach
of storing the bits in a bitmap.

In any case, I don't think this should be a blocker, if this were the
only problem it can be merged as is and improved in future pull
requests.

> I'm also hoping for a comment on the ambiguity of TypeInfo_Class. If
> implementing TypeInfo_Reference, what would
> TypeInfo_Reference.toString return? "C ref" as in Michel Fortin's
> implementation of tail const references? ;-)

I can't really comment on this one, not very familiar with them either.

-- 
Leandro Lucarella
Senior R&D Developer
Sociomantic Labs GmbH <http://www.sociomantic.com>