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