On 1/10/14 12:37 PM, Rainer Schuetze wrote:
* At this point I won't worry about discovering roots; I assume druntime
has the appropriate mechanisms in place.
It currently does not have precise information, but it is dearly needed,
too.
Yah, that's where I'm counting on your work :o).
* 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.
I guess the mark function will be stored somewhere in the TypeInfo. How
is this going to work with dynamic and associative array operations if
these are not also templated?
I need to write some code to explain it all. An figure it all :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.
So no more std.emplace?
std.emplace will continue to work as a way to build an object at a
specified address. I suspect that allocating and manipulating objects on
the GC heap in particular may have certain restrictions. One possibility
to avoid such restrictions is to have a function typify(T)(void* p)
which ascribes type T to heap location p.
* 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 might help in having different heaps (especially thread
local heaps if you include "shared"), but I'm not sure this works in
unsafe D where casting is allowed.
Type-forging casts have always been somewhat implementation-defined. The
way I see it they'll continue to only work for people who really know
what they're doing. I'm not too worried about that.
* At this point I'm unclear on how generations can be componentized, but
am cautiously optimistic. Will see once I get to it.
One thing that would be great now would be to make an effort to review
and merge the current precise GC work. I'm sure it will be of great help
with breaking into components.
As written in the other thread ("how to contribute to GC"), I have just
made an attempt to make it more reviewable:
https://github.com/rainers/druntime/commits/gcx_precise2
The necessary compiler fixes are here:
https://github.com/D-Programming-Language/dmd/pull/2480
Yah, time for you to get some destruction first :o).
Andrei
