Yes, you can help std.allocator!

[Rikki Cattermole via Digitalmars-d]

On 5/04/2015 3:16 p.m., Andrei Alexandrescu wrote:
> Following up on Brian's nice offer:
>
>> What's going on with std.allocator? I have a few projects (some on
>> Github, some at EMSI) that use it because it seemed like it was on
>> its way to being in Phobos. What can I do to help with this?
>
> Things are going well with std.allocator. I broke the code into a
> package with modules, which makes it quite nice to deal with. Also I
> just implemented a simple heterogeneous freelist allocator akin to the
> Kernighan-Ritchie one:
>
> http://erdani.com/d/phobos-prerelease/std_experimental_allocator_kernighan_ritchie.html
>
>
> I did so more for demo/historical perspective purposes. I plan to add
> the part that adds new chunks on a need basis as a separate artifact.
>
> Now there _is_ something I could help with.
>
> 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.
>
> What would really help this evaluation and any other work on garbage
> collection would be a modularization of the tracing process.
>
> I'm envisioning a simple API that separates the system-dependent part of
> the tracer (stopping all threads, finding the roots in the globals, TLS,
> and stack) from what the collector is supposed to proceed with the tracing.
>
> So I'm thinking e.g. of a range that would iterate through all untyped
> words on all stacks as void* data.
>
> foreach (void* p; GC.traceAllStacks)
> {
>      ...
> }
>
> Then we'd have typed data in TLS and globals. I guess those would come
> as ranges of Tuple!(void[], Typeinfo) or something similar.
>
> I'm sure I'm glossing over a number of details, so I'd need an expert in
> the GC workings to help me connect std.allocator with it. Once the GC
> has a low-level tracing API, I can figure what primitives I need to add
> to std.allocator to accommodate tracing.
>
>
> Thanks!
>
> Andrei

Moving the GC out of druntime, might be an interesting proposition.

Pro:
- D is no longer "garbage collected"
- Easier to swap implementations

Cons:
- Technically none for the embedded guys
- Quite a lot of work to get the current GC refactored into new design
- Good bit of changes to phobos/druntime

But this would most likely go a long way towards the goal of @nogc I think.