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