std.allocator: primitives for helping GC

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Thu May 1 08:36:11 PDT 2014


On 5/1/14, 8:00 AM, "Marc Schütz" <schuetzm at gmx.net>" wrote:
>
> This marking will usually be implemented by setting a flag near the
> memory in question, which is not COW and cache friendly, because it
> tends to write all over the place.

Depends. HeapBlockWithInternalPointers uses the same flag as the 
allocation flag (nice!), and all flags are together at the front of the 
managed chunk. One perk is that once tracing is done, there's nothing 
else to do - free memory stays free.

> For this reason, some GCs use a temporary bitmap for marking, and leave
> the marked memory untouched. By pushing the marking to the specific
> allocators, this can no longer be implemented globally.

Yah, probably I'll implement such a tracer too. For more generality (to 
work on discontiguous blocks of varied granularity) I'm thinking of 
having it use an interval tree instead of a bitmap.

> But I guess a GC is not required to use these helper functions, so I
> guess it's fine...
>
> And just to be sure: doneMarking is _not_ supposed to actually free the
> memory (and call the destructors), is it? That's still the GC's job, right?

Yah, doneMarking would only do whatever low-level postprocessing the 
untype GC would need to do. Calling dtors will be done right after that.


Andrei



More information about the Digitalmars-d mailing list