GC problem (finalisers) & comments

James Kevin Doyle jdoyle at rhea.cs.umass.edu
Wed Apr 9 08:57:22 PDT 1997


> [Diagnosis of finalized Thread problem]

> But this still leaves the problem that you end up with live objects
> referencing free memory which is unsound. If having a finaliser means we
> shouldn't free the memory first time its garbaged (which for the moment
> I don't quite understand why this is so) then surely the only safe thing
> to do is to put all referenced objects into the same state and not free
> them this time. 

You are right:
Objects that have become unreachable from roots and are to be finalized
are considered "f-reachable"; anything reachable from something f-reachable
is also f-reachable.  Anything that is f-reachable must be preserved and 
not freed.  So, any object put on the finalizing list must be marked itself.
In the example above, the Thread object is f-reachable, and its pointed-to
String object is f-reachable.  A proper implementation must keep both
alive until the finalizer has been called, at which point regular 
reachability again governs their preservation.

It was my impression that this is accomplished in Kaffe by virtue
of the fact that the finalizing list is accessible from the Finalizer
Thread object, which itself is marked and walked.  Is this true?

> Also, is there any guarantee of order here, can't we
> free a referenced object before the referencer? I am sure there is
> standard stuff to do here (can't remember the stuff in the various
> papers I've read).

If the parent and child (referencer and referenced object) are both
not reachable *and* not f-reachable, then the order of "freeing" is 
irrelevant.  No further computation will be able to see either of the
objects.  If the objects are still f-reachable, then no order of freeing
is correct, because computation is pending, and the parent as well as the
child may be accessed.

The idea of finalizer-order is different, though, since you're ordering
computation that is visible to the application.  Java, however, specifies
no particular order of finalizer execution.

> -- 
> Bernie Solomon (bernard at edsug.com or Bernard.Solomon at acm.org)
> Unigraphics Architecture, EDS-Unigraphics, Cambridge, UK
> 
> 

Referencing Section 12.6.1 ("Implementing Finalization") in the Java
Language Specification by Gosling,Joy,and Steele may help clear up the
subtleties of what finalization means and requires.

Cheers,
Jim Doyle
jdoyle at cs.umass.edu



More information about the kaffe mailing list