Componentizing D's garbage collector

[Andrei Alexandrescu]

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