On 10.01.2014 22:42, Andrei Alexandrescu wrote:
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 was thinking about using the proposed module info extension to
generate data similar to RTInfo by interpreting global/tls data of a
module as a struct with type info. I don't know if this is feasable.
* 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).
Waiting eagerly for the code :-)
* 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.
That sounds similar to my gc_emplace function. The problematic part is
how to save that information in the GC.
* 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).
Ready to get some blows...
