On 1/10/14 3:29 AM, Dmitry Olshansky wrote:
10-Jan-2014 12:03, Andrei Alexandrescu пишет:
* 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.
You know I wouldn't write that unless I had an ace up my sleeve. Watch
me :o).
* 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.
That design will disappear. The attribute won't be settable once
initialized, and will never be conservative ("scan all words in this
block").
* 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.
Yah, separation of shared data allocation is crucial. We'll see.
Andrei
