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