[gclist] Precise GC's performance [really finalization protocol]

[Mike Spertus]

> mps@geode.geodesic.com (Mike Spertus) wrote:
> > If I understand you correctly, any object in a cycle of finalizable objects 
> > will be marked, preventing finalization of the object for eternity. Also,
> > I don't see why it matters whether you defer the marking to this stage.
> 
> I don't believe so---IF the cycle is purely between the finalizable
> objects, AND if none of them are revived during the "kill methods", then
> the next time round the GC they are no longer on the list of
> finalizable objects, and hence form a detached cycle unreachable from the
> roots.
> The fact that they get marked this time does nothing more than defer
> their collection one GC-cycle.  The removal of the objects from the
> finalizable list is the key thing---it demotes them to the status of
> normal objects after the kill method has been run.
> 
> Does this clarify things?
> 
The whole reason for doing the mark from the finalizable objects is to
ensure that destructors are run in the correct order. When A->B and B->A,
there is no correct order. More specifically, Suppose A points to B and 
B points to A. I can't run A's destructor first, because B's destructor might 
use A. I can't run B's destructor first, because A's destructor might use B. 
It does me no good that the memory isn't deallocated because there is no 
assurance that A is well-formed after its destructor is run. For example, if 
A's destructor releases a Windows resource or manually managed memory and B's 
destructor uses A to reference this resource or memory, there will be 
big trouble. 

Personally, I think that the best thing that can be done in this situation is 
to leave the cycle, which is what both of our schemes do. So I agree that 
requiring cycles of finalizable objects to be broken by hand is the 
"right thing", but it also has to be listed as a potential disadvantage as well.