Componentizing D's garbage collector

[Rainer Schuetze]

On 11.01.2014 22:20, Benjamin Thaut wrote:
> Am 11.01.2014 21:44, schrieb Andrei Alexandrescu:
>> On 1/11/14 3:52 AM, Benjamin Thaut wrote:
>>> Am 10.01.2014 20:40, schrieb Andrei Alexandrescu:
>>>> On 1/10/14 11:34 AM, Benjamin Thaut wrote:
>>>>> Am 10.01.2014 09:03, schrieb Andrei Alexandrescu:
>>>>>>
>>>>>> Destroy.
>>>>>>
>>>>>> Andrei
>>>>>
>>>>> Just one question. Did you read "the garbage collection handbook"?
>>>>
>>>> Yah, the new edition. Unfortunately I didn't find a lot of new stuff or
>>>> things that would help in a practical implementation.
>>>>
>>>> Andrei
>>>
>>> Very good,
>>>
>>> In my opinion it should be required for everyone who wants to
>>> participate in D's GC to read that book. So everyone has at least a
>>> basic understanding of the problem at Hand.
>>>
>>> But if you read the book I don't understand, why you simply declare the
>>> hardest problem, percise pointer discovery, as done. To be able to
>>> actually implement and test a GC that is not a reimplementation of what
>>> we already have one needs percise pointer discovery of _all_ pointers,
>>> write barriers and GC halting points. So please enlighten me why you
>>> simply decalre this done?
>>
>> I'm not considering done as much as separable as a concern. All I'm
>> saying is I hope to be able to separate the low-level part of
>> discovering roots from the high-level part of marking used memory. BTW
>> the way I see this done is "mostly precise", i.e. there will be at least
>> for a while some words that will be handled conservatively (stack,
>> registers, certain union members).
>>
>> If there's anything in the GC book that suggest that would be
>> impossible, please do let me know!
>>
>>
>> Andrei
>>
>
> Well as far as my understanding of GCs goes, you have two options:
>
> 1) Impercise pointer discovery => limiting yourself to a mark & sweep
> 2) Percise pointer disccovery => option to use a semi space GC in
> combination with a mark & sweep and generations, which allows for
> superior handling of short lived allocations (which is the biggest
> problem of D's current GC).
>
> Also without percise pointer discovery you will never be able to move
> objects from one heap into another. This would be especially a problem
> for the immutable heap, because you might want to allocate all strings
> on the thread local heap until you discover that you actually need them
> to be shared between threads. You might also need to move objects into
> antoher heap whenever a casts happens or global variable is assigned.
>
> Kind Regards
> Benjamin Thaut

I think a moving collector is currently not feasible without restricting 
the language a lot, probably similar to safe D and more. I'm not sure we 
want that in general.

We should aim at something in between mark & sweep and compacting 
generational collection, e.g. a non-moving collector that keeps track of 
the youngest generation (I just made that up, not sure if it is 
realistic). Adding concurrency would also be nice...