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