Componentizing D's garbage collector

[Dmitry Olshansky]

10-Jan-2014 12:03, Andrei Alexandrescu пишет:
> 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 at http://goo.gl/ZVCJeB seems to be a win.

O.T.: Please use full URLs, it's not that long.

Also how about actually starting formal process to include it as 
core.alllocator (package preferably).  This activity can go in parallel 
with with getting a through reveiw of currrent GC and taking steps 
towards precise GC into the mainstream.

> I've started with the next logical step - higher-level allocation that
> is aware of the type of the object being allocated, and realized that
> integrating a notion of tracing is appropriate at that level, and
> actually quite easy. So I'm thinking of just doing it.
>
> A few highlights:
>
> * 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.

Cool so far.

> * 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 not work AFAICT. Since nobody can tell what kind of type a
user-defined program may have and GC is certainly not templated on all 
types.
GC would have to rely on TypeInfos or rather RTInfo-s that describe the 
layout of Ts in a uniform way (bitmaps to indicate pointers, etc.).
I think Walter had some ideas on how to represent these to reduce space.

> * 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.
>

Yup. I though GC already did something like that, with BlkAttr.NO_SCAN.

> * 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.)

Would that mean 3 separate heaps, so that addresses given for immutable 
stuff would never be (sometime later) assigned to (thread-local) 
mutable? I might have got this point of yours wrong, but I think there 
is a merit in having separate heap at least for shared stuff.

-- 
Dmitry Olshansky