Success! (Precisely)
Denis Koroskin
2korden at gmail.com
Fri Oct 30 09:27:33 PDT 2009
On Fri, 30 Oct 2009 08:08:10 +0300, dsimcha <dsimcha at yahoo.com> wrote:
> After a few evenings of serious hacking, I've integrated precise heap
> scanning
> into the GC. Right now, I still need to test it better and debug it,
> but it
> at least basically works. I also still need to write the templates to
> generate bit masks at compile time, but this is a simple matter of
> programming.
>
> A few things:
>
> 1. Who knows how to write some good stress tests to make sure this
> works?
>
> 2. I'm thinking about how to write the bitmask templates. In the next
> release of DMD, when static arrays are value types and returnable from
> functions, will they be returnable from functions in CTFE?
>
> 3. new only takes RTTI. It is not a template. Unless RTTI gets
> bitmasks in
> the format I created (which I'll document once I clean things up and
> release,
> but has only deviated slightly from what I had talked about here), stuff
> allocated using it won't be able to take advantage of precise heap
> scanning.
> The default bitmask, if none is provided, uses good (bad) old-fashioned
> conservative scanning unless the entire block has no pointers, in which
> case
> it isn't scanned. This means that we have all the more incentive to
> replace
> new with a template of some kind.
>
> 4. I solved the static array problem, but the solution required using
> up one
> of the high-order bits. We have at least one more to play with in my
> bitmask
> scheme, because I'm storing things by word offsets, not byte offsets,
> since
> the GC isn't supposed to work with misaligned pointers anyhow. This
> leaves
> one more bit before we start limiting T.sizeof to less than full address
> space
> (on 32-bit, where a word is 4 bytes). I think it needs to be reserved
> for
> pinning, in case a copying collector ever gets implemented. If we're
> willing
> to not let any precisely scanned object have a T.sizeof of more than
> half the
> address space (a ridiculously minor limitation; this does not limit the
> size
> of arrays, only the size of classes and the elements of an array), we
> could
> throw in a third bit for weak references.
Blaze (http://www.dsource.org/projects/blaze) is often suggested for
stress-testing the GC. Probably, because it does huge amount of dynamic
allocations, while total amount of memory consumed is about the same.
Worth a note, it's for D1/Tango, but you said you were going to port it to
Tango, too, so it may be better to start with Tango (because there are a
lot more code written against Tango and you get instant user feedback) and
then port it to druntime. If not a performance test, it may be a good
correctness test (so that you don't collect memory which is still
referenced).
More information about the Digitalmars-d
mailing list