just to make a point what you are talking about is not destruction (as in c++) but finalization (as in any gced language) the difference being in the determinism. Destruction is almost always necessary in c++ since the memory allocated need to be deallocated. Like you justly specify finalization is only needed to release over type of ressources than memory (file handles, db connections...) in any case finalization is never determinist and should not be relied on which means the objects representing say a file should have an additional close message used for normal closure the finalizer being only used as a fallback against badly programmed clients to the api... An important thing is that it is generally OK to have to pay a non negligible speed cost when implementing a finalizer since this should be the exception rather than the rule while it is not OK to pay a non minuscule speed price for those objects which do not have a finalizer. Benoit
----- Original Message ----- From: "Michael L Maraist" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, December 10, 2001 4:48 AM Subject: gc object destruction 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
