Componentizing D's garbage collector

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Fri Jan 10 08:22:56 PST 2014


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


More information about the Digitalmars-d mailing list