One of the interesting side-effects of a copying collector is that we can't inherently determine which objects need to be destructed (their memory space just gets reused without notifying anyone). I'm already looking to use some algorithms that utilize linked-lists to determine set-association. Most notably the PMCs... I'm thinking that we won't perform object destruction during DoD, but instead flag the PMC as being in prior use once it's allocated, and at some point it'll find its way back onto the free list after DoD.. When it's allocated from again, a destructor can be called (to close file-handles, etc). The big problem with this is that the memory to which it referred will already have been collected by this point... Closing a file-handle, for example, wouldn't be able to just flush any parrot-level data-structures, since this could be the last few clock-ticks of the parrot apps life, and prior buffers have already been thrown away.
I hadn't really concerned myself with it until I noticed at my work the WeakReferences library within Java.. They use a tiered system for object references.. "Reference" which is an explicit object class which is used by the various memory management "hacks". SoftReference, which is useful in caches, since it's associated object will not be prevented from DoD and thus reclaiming. It's contents need to be set to undef if a reclaim has occured, however. WeakReference, which is useful in triggering activities on DoD (such as clearing hash-keys), and finally PhantomReference, which effectively lets you write object destructors around an object before anything bad happens to it in the DoD stage. What functionality do we want our destructors, weak-references, etc to have, that the GC should know about? -Michael
