GC implementation, Interface

[Don Clugston]

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.