Componentizing D's garbage collector

[Rainer Schuetze]

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...