GC implementation, Interface

[Sean Kelly]

Don Clugston wrote:
> Frank Benoit wrote:
>> MicroWizard schrieb:
>>> As far as I know the D GC can be replaced.
>>> There are many GC theories and I think most of them can not be 
>>> corrupted with
>>> garbage. (They handle with working sets, aging and so on.)
>>>
>>> The problem is not a problem IMHO
>>
>> Yes, you can exchange the gc. But at the moment we have this
>> implementation, a conservative one. And as non-compiler-implementor I
>> cannot change the gc from conservative to precise, because the interface
>> lacks of the reference information.
>>
>> In serveral papers i red that it is not possible to make a gc, that is
>> optimal for all applications.
>>
>> This said, it would be a good thing to have an open standard to
>> integrate own GC implementations. This can help D in various ways.
>> - Multiple implementations can show the advantages of each way
>> - Each application can tune the used GC.
>> - Special solutions for special cases are possible (e.g. realtime,
>> gaming, secure applications)
>> - The D community can contribute to the GC implementation work
>> - D can become a GC laboratory :)
>>
>> The current interface serves only for a stop-the-world conservative GC
>> implementations. Other implementations require some kind of compiler
>> assistance. e.g. read/write barrier, information about position of
>> references, sychronisation points,  etc.
>>
>> For an interface which should serve for many possible GCs, it should 
>> support
>> - stop-the-world, incremental, concurrent
>> - copying, mark-sweep
>> - moving, non-moving
>> - generational GC
>> - ??? Building Objects out of blocks => no fragmentation ???
> 
> Have you had a look at Sean's work in Ares? He's been addressing this 
> very issue.

The big missing piece at this point is a way to tell the GC what 
portions of allocated memory may contain pointers.  Some of this will 
require improved RAII, but some could be done now.  I've been 
considering adding an additional parameter or two to gc.malloc, 
gc.calloc, and gc.realloc to pass this information.  But since it would 
also require modifications to the GC (with which I'm not entirely 
familiar) I haven't done so yet.


Sean