GC problem (finalisers) & comments
bernard at UG.EDS.COM
Thu Apr 10 03:43:19 PDT 1997
James Kevin Doyle wrote:
> 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?
The finaliser loop (finaliseMan in gc-incremental.c) simply walks down
the list of objects to be finalised (sorry about the s's but I'm a Brit
too!) and if an object needs a finaliser called calls it and if that is
significant doesn't free the memory. However each object is treated
completely independently and in one loop hence ignoring the whole
f-reachable concept. One thought I had was to go down this loop and
simply stop doing any freeing as soon as you hit the first object with a
finaliser but this relies on hitting parents before children - I am not
sure whether this is the case - I suspect not. Of course another
possiblity is to do a mark scan to get all f-reachable objects correctly
(maybe this is in fact *necessary* rather than just possible).
> 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.
True - I think the problem is just that f-reachable isn't a concept in
the current implementation.
> 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.
That's what I would expect.
> 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.
A good reference and the state diagram definitely helps.
However I personally don't currently have time to try and fix all this
up though it does seem something important to mend.
Bernie Solomon (bernard at edsug.com or Bernard.Solomon at acm.org)
Unigraphics Architecture, EDS-Unigraphics, Cambridge, UK
More information about the kaffe