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

[Frits van Bommel]

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?)

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. 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)
If we go the fake ClassInfo approach, the ClassInfo.init.length field could be 
used to store this size.
Note that this would likely mean initializing unused parts of memory blocks to 
null[1], since the GC doesn't know how much of them is used and might get false 
pointers otherwise.

All in all, maybe it'd be easier to just go the TypeInfo approach. The extra 
information needed to support non-class types is already conveniently available 
there (type sizes, postblits for D2) and they're already available for all types...
Or maybe the ClassInfo in the vtable could be changed into a TypeInfo? :)


[1]: At least for array blocks. Other blocks likely wouldn't have enough padding 
for extra elements -- unless the extra pointer for non-objects puts the size 
over the limit and the block size is doubled.