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.
