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

[Walter Bright]

On 8/23/2010 5:32 AM, Leandro Lucarella wrote:
> That's why I think the pointer bitmasks generation should be added to
> DMD, it doesn't affect the runtime, unless you explicitly use that
> information, it doesn't mean you have to provide a precise scanning GC
> by default.
>

1. I think your idea of grouping static data that doesn't need to be scanned 
separately from static data that does is a good one. It means putting them into 
a different 'segment' in the object file, analogously to the way moduleinfo and 
eh tables are emitted into different segments.

2. Adding simple bitmasks to the typeinfo doesn't work that well - what to do about:

     struct S { ... }
     struct T { S[1000] s; }

It would generate a giant bitmap.

3. An idea (I think it was Andrei's) was for the TypeInfo for each type to have 
a virtual function that gets called by the GC to "scan this object". The 
advantage of this is it is completely flexible, and for many types custom 
marking code is going to be far faster than table driven, especially if that 
table is compressed.

4. Eventually, I'd like to add to TypeInfo's an array of [offset,TypeInfo] pairs 
for the fields. While awesome in power, that's going to be slow for the GC to 
use, hence the idea (3) for that.