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

[Frits van Bommel]

Robert Jacques wrote:
> On Tue, 14 Apr 2009 06:04:01 -0400, Frits van Bommel 
> <fvbommel at remwovexcapss.nl> wrote:
>> Robert Jacques wrote:
>>> 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.

I already mentioned the bitmask overhead could be bounded to pointer-size by 
falling back to a TypeInfo-based solution for memory blocks where that overhead 
would otherwise exceed (or match) the size of a pointer.

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

Oh, I didn't know that. (I haven't done much of anything with D2, I mostly stick 
to D1)
I just presumed they were like C++ copy constructors.

As an aside: I can certainly think of some places where it would be useful to 
have them get called whenever the address changes...
(Though "move constructors" would be even better for most of those cases)

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

You'd still need to know the size of the bitmask, to know after how many bits to 
repeat it.
But like I said, a ClassInfo would encode the size of the type (as does 
TypeInfo), so any solution based on either of those should do the trick here.