Yes, you can help std.allocator!

[Laeeth Isharc via Digitalmars-d]

On Sunday, 5 April 2015 at 03:16:32 UTC, Andrei Alexandrescu 
wrote:
> 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:
>...
> 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 cannot think of much I can do to help - I just started reading 
the GC code on the ferry over - but this is very cool.  
Intrinsically, and because it addresses a perception that is an 
impediment to adoption (even though I reckon people make a lazy 
mental association of GC with problems associated with Java in 
its early days when it actually might not be a real barrier for 
many of them  with D today in their actual use case - just like 
the spurious 'D has two standard libraries' meme).

Only one suggestion - I know there are some GC benchmarks in 
Phobos/Druntime.  Might it be an idea to relate these to some of 
the standard benchmarks people use to evaluate GC in other 
languages, so people have clarity on the tradeoffs.  We don't 
need to make these salient until the time is right.