GC implementation, Interface

[Frank Benoit]

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

So I try to begin with a few thoughts about such a "GC integration
interface" - GCII:

Reference info for classes, structs:
The allocation function of the GC should not only receive the size of
memory, which is required. It should also receive a bitfield with the
information, which words in this memory are references.

Reference info for the stack:
each stack frame begins with the bitfield with reference information.
If the GC scans the stack, the frames have to be recognized.
This could be dissabled for a conservative GC.

Read/Write Barrier:
Some GC need to run some code each time a reference is overwritten
and/or if a reference is read.
A flexible way can be, to give the compiler an function, to use for read
and write accesses. These functions should always be inlined and
optimized. e.g.:
___ref_assign( void * trg, void * src ){ trg = src; }
void* ___ref_read( void * src ){ return src; }


Does this make sense?
Please make additions.
	

Frank Benoit
^^@^^-^^^^^^.de