GC problem (finalisers) & comments

[Bernie Solomon]

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.

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