Componentizing D's garbage collector

[Sean Kelly]

On Friday, 10 January 2014 at 08:03:03 UTC, Andrei Alexandrescu
wrote:
> The GC comes up repeatedly in discussions around here. I've 
> been thinking for a while about breaking it down into 
> components, and now it seems the time is ripe.
>
> * The design will foster the small, composable components with 
> required/optional primitives that worked for std.allocator.
>
> * I plan to review and probably discard all of the 
> pointers-to-functions nonsense in the current GC.

This only exists because the runtime is statically linked and
supporting D in a DLL was a requirement.  Grafting together GCs
from multiple runtimes was the easiest way to do this at the
time, but the correct solution is really just to put the runtime
in a DLL and jettison the whole idea of a GC proxy.  In short,
I'm all for it.


> * I plan to rely on static introspection for the mark function, 
> i.e:
>
> void mark(T)(ref T obj);
>
> would mark obj and everything transitively referred to by it. 
> The function would probably take a second parameter that's the 
> heap that obj is sitting in.

This will take some work.  Maybe thread_scanAll can take an alias
to such a function instead of a function pointer as it does
today.  Something along those lines anyway.  In short, the
template part is what's tricky about this approach.


> * I plan to segregate all objects that don't include references 
> and pointers (e.g. int, int[], Tuple!(int, double) etc) into a 
> completely different heap than the "interesting" objects. For 
> the simpler objects there's no need to save detailed type 
> information so they can be stored in a more compact, efficient 
> manner.

Yay!  I don't like how the current GC mixes these and indicates
the presence of pointers via a bit flag.


> * There will be no possibility to change the type of certain 
> objects once allocated. An allocation for an immutable object 
> cannot e.g. make it later a mutable one. (This is an essential 
> issue with the current allocator, I think.)

I think this is reasonable, since it also may affect which pool
the data is allocated in.  I really would love to aim for a
concurrent allocator scheme.  Kinda like HOARD but with a GC
attached.  But this is really only feasible if you make some hard
assertions about type conversion.