Success! (Precisely)

[Jacob Carlborg]

On 10/30/09 14:29, dsimcha wrote:
> == Quote from Jacob Carlborg (doob at me.com)'s article
>> On 10/30/09 06:08, dsimcha 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.
>> Would this be possible to use with D1 ?
>
> The precise heap scanning would probably work, if the bit masks were generated
> manually, but I don't know if D1's templates are powerful enough to generate them.
>   I had D2 in mind as a target, but I'll document the format once everything's
> cleaned up, tested, etc. and if someone wants to try to make it work on D1, they can.
>
> The only thing, though, is that D1 is supposed to be stable, and adding bit masks
> as an argument o GC.malloc might not fly.  Then again, it would only be a lib
> change, probably in Tango.  Furthermore, I made old-fashioned conservative
> scanning the default (a bit mask called conservativeBitMask is stored in the
> static data segment and is the default argument to GC.malloc) specifically to
> avoid breaking any compatibility at the source level.

Ok, well I didn't think phobos would change so I was think about the 
possibility to add this to tango. It seems it's mostly a runtime thing 
but I may be wrong.