Yes, you can help std.allocator!

[Martin Nowak via Digitalmars-d]

On 04/05/2015 05:16 AM, Andrei Alexandrescu wrote:
> Right now the allocator design works well as a flexible malloc/free
> implementation, but has no support for tracing-based garbage collection.
> 
> I am evaluating whether I should add tracing capabilities to
> std.allocator, or stop here. Tracing would most definitely require new
> primitives such as embedding some sort of type information and resolving
> internal pointers.

Just to make sure we're on the same page here.
You're talking about implementing the GC in terms of std.allocator, not
about making std.allocator GCable, right?

This would be fairly interesting for us too experiment with, as we could
easily try out different allocator architectures. But then again the GC
needs to use highly optimized data structures to lookup metadata, we'll
likely only choose a single allocator architecture, and we already know
a few good ones
https://code.dawg.eu/talks/2015-03-20-garbage_collection_dmeetup/#9.

So while the heap layer idea is interesting and would facilitate to try
different allocators, it's a substantial amount of work, to add the
marking and metadata to std.allocator.

We already started to modularize the GC a little and can try out
different architectures by hand, so I don't think it's worth the effort.

> What would really help this evaluation and any other work on garbage
> collection would be a modularization of the tracing process.

It's already pretty much like that.

http://dlang.org/phobos/core_thread.html#.thread_suspendAll
http://dlang.org/phobos/core_thread.html#.thread_scanAll
http://dlang.org/phobos/core_thread.html#.thread_resumeAll

Scanning is not a range but callback based and misses GC.addRoots and
GC.addRanges, wouldn't be too much work to add that.
https://github.com/D-Programming-Language/druntime/blob/7877f65a6baf53b0c53c1babf9a0f0a5d1893940/src/gc/gc.d#L2205
There is also no TypeInfo yet.

-Martin