On Tue, 14 Apr 2009 09:27:09 -0400, Frits van Bommel <fvbom...@remwovexcapss.nl> wrote:
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.

Sorry, I've been looking at non-frreelist based GCs where that optimization is not available. Also, there are some limitations associated with a variable length page header might be an issue. (i.e. a free page with 512B blocks can't be re-purposed as a page with 256B blocks.)


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)

Could you document this use case? (i.e. give some examples as I can't think of any)


Reply via email to