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