[dmd-internals] Giving better static data limits to the GC

[Andrei Alexandrescu]

I'm thinking - it's been the hallmark of druntime (vs. Phobos1) for the 
longest time that it has a configurable GC. How about this - let's make 
the precise GC a custom collector. This would allow us to (a) compare 
the existing GC with the proposed GC and (b) tune druntime's details 
with a real-world alternate GC.

Is that all possible?

Andrei

On 08/22/2010 04:57 PM, Leandro Lucarella wrote:
> Walter Bright, el 22 de agosto a las 12:25 me escribiste:
>>   I know this is probably really low priority for DMD, but any answer
>>   would be appreciated, even if it is something like "no idea how doable
>>   it is, it would take time to think about it and is low priority" :)
>>
>>
>>     I don't think spending a lot of effort on the static data is worthwhile,
>>     as very little of modern programs should consist of static mutable data.
>>
>>     What's held me back from adding in precise scanning data for everything is
>>     the large expansion of the memory footprint of a program to hold all this
>>     data.
>
> Thanks for the answer. My experiments show that static data is relevant.
> Comparing 2 GC implementations, one with very few types (druntime
> implementation) and another using a few more types, including a couple
> of templates, the second is measurably slower. The types generates
> a *lot* of rw static data.
>
> Even when I agree that it might be too much to add type information to
> the static data, grouping only the static data that should be scanned
> (i.e. D-only global variables, and leaving out all the
> TypeInfo/ClassInfo) can make a big difference.
>
> Would that be too hard?
>
> Right now I'm under the serious dilemma of whether I should got back to
> the more messy way of coding (with few types) or pay the price, which is
> a very hard decision because I don't want to make the code uglier but
> I don't want to have a slower GC either.
>
> Thanks.
>