Dan Sugalski <[EMAIL PROTECTED]> wrote:
> So, being clear here (I hope, though recent history suggests
> otherwise) what I want is the API that the GC/DOD system presents to
> the rest of the engine. This includes the functions you call to
> trigger a DOD or GC sweep, any functions or macros that need to wrap
> pointer fetches or stores (if any), what stats are kept, the
> functions it exposes to the allocation system, or what parts of the
> allocation system it peeks at.
I'm currently thinking of something like that:
Parrot_gc_XXX_init(Interp *) // init GC system XXX
This function has to fill the following function pointers in C<arena_base>
PObj * arena_base->get_free_object(Interp *, Small_Object_Pool *)
void arena_base->do_dod_run(Interp *, int flags) // normal, lazy ...
void arena_base->de_init_gc_system(Interp *) // free resources
void arena_base->mark_object_live(Interp *, PObj *)
The latter could have a macro form too that e.g. does nothing if the
object is already marked live.
Arena_base is divided into 2 parts: the public part holding these
function pointers and common statistic variables and a private part for
that GC system.
Statistics are basically the same as now, plus an interface to private
statistic data for that GC system.
Finally the GC/DOD system might need a write barrier:
DOD_WRITE_BARRIER(interp, aggregate, old_item, new_item)
For hash keys we might need either two such calls (the 2nd with keys) or
an extended form that both takes keys and PObj*.
I think we can ignore read barriers as these systems are too slow to be
usable.
All the DOD related flags (live, on_free_list) are private to the GC
system. The public part is to set custom_mark, _destroy, array_of_PObjs,
and _needs_early_DOD.
The allocation system is only accessible by ->get_free_object(). That's
all. [1]
The current stop-the-world M&S "DOD" is spread over dod.c, headers.c,
and smallobjects.c. Incremental M&S has its own allocator but reuses
parts of these files.
The proposed implicit reclamation system would have separate
pobject_lives and mark routines and its own pool allocator that contains
the forward and backward object pointers. Marking an object live is
chaining these pointers so that the PObj* is "moved" from the
C<from_space> into the C<to_space>.
Comments welcome,
leo
[1] we might consider an explicit opcode C<unused {Px, Sx}> though,
which could be emitted for temporariers. I know that we had C<destroy>
some time ago (at that time I thought it would be unneeded ;) But it
could take pressure from the GC system.
