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.
Works.
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.
I'm OK with this. I'm also OK if we want to just define the public API and have the functions be real functions rather than vectoring indirectly. That'd mean no runtime GC changes, but I'm not sure that's bad.
Statistics are basically the same as now, plus an interface to private statistic data for that GC system.
We probably want to add a partial sweep count too, since some of the systems will allow for partial sweeps through objects.
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*.
How 'bout instead we have:
STORE_POINTER(interp, dest_pmc, address_to_write, value_to_write)
If we use this only to write pointers to DOD-tracked things we know the destination value must point to a PMC (or gc object at least) as must the value it's replacing. Should work for arrays and hash stores just fine too.
I think we can ignore read barriers as these systems are too slow to be usable.
I agree. Without hardware support the schemes that need read barriers are really slow.
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.
Yeah, it's a mess. It used to be just in resources.c (or dod.c, it's been a while) but it's been worked on a lot since it was first written.
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>.
That works too. I think we may want to formally spec the API and the internals of the allocation system. While I'm not too thrilled about exposing all the guts, it'll potentially speed up reclamation of dead objects a lot, and that's not a bad thng.
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.
I'm all for putting destroy back in. It'll still be somewhat limited (the thing being destroyed can't go onto the free list until the DOD gets to it) but it'll be immediate and potentially gives the DOD fewer things to go trace.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
