(Semi) precise GC [was: Re: Std Phobos 2 and logging library?]

[Robert Jacques]

On Tue, 14 Apr 2009 06:04:01 -0400, Frits van Bommel  
<fvbommel at remwovexcapss.nl> wrote:
> Robert Jacques wrote:
>> On Mon, 13 Apr 2009 14:54:57 -0400, Frits van Bommel  
>> <fvbommel at remwovexcapss.nl> wrote:
> [snip]
>>  An alternative to this is to encode the information in ClassInfo and  
>> use
>
> It's already there. That's where TypeInfo for classes gets it from :).
>
>> it instead. (You'd have to create a fake ClassInfo for structs and  
>> arrays.) Then the GC only has to track the start of each object (i.e.  
>> the beginning of a block in the current GC). The advantage is that this  
>> has 0 storage requirements for objects and on average < 4 bytes for  
>> structs and arrays (thanks to the coarse block sizes of the current GC).
>
> (that'd be < 8 for a 64-bit machine?)

Yes. The key point it's a per item cost which decreases with item size, as  
opposed to a fixed 6.25% overhead when using a dense bitmask.

> An interesting idea. Indeed, since vtables for objects start with a  
> ClassInfo reference, putting a ClassInfo* in front of non-object memory  
> blocks should work, if ClassInfo could be generalized to support  
> structs, unions, ints, floats, etc...
>
> Using D2 structs with a moving GC would need some extra bookkeeping data  
> anyway, to work out things like their postblit call.

Postblit is only called when generating an actual copy. For example it is  
not called on assignment is the source is no longer used. So I don't see  
any reason why it should, or it would be expected that postblit would run  
when a struct was moved using the GC.

> This could be put in the ClassInfo or in the second slot of the fake  
> vtable.
> (Without the fake classinfo, using a TypeInfo reference instead of the  
> bitfield and putting it in there would work too)
>
>
> Arrays, by the way, would also need some special handling, since you  
> can't return a variable-sized OffsetTypeInfo[] without allocating during  
> collections.
> (As long as they fit in the limits for the bitfield, that could be  
> repeated though -- as long as it's not an array of structs with  
> postblits...)
> So maybe a .sizeof should somehow be included, and the offsets assumed  
> to repeat after that? (as long as enough bytes are left for at least one  
> more item)

Actually, I'd assume there'd be an isArray flag in the Class/Type Info,  
which would cause the bitmask to be repeated until the end of the block.