[jmm-dev] finalization (was: ECOOP, JVMLS)

Doug Lea dl at cs.oswego.edu
Tue Aug 5 00:11:01 UTC 2014

On 08/03/2014 12:39 PM, Jeremy Manson wrote:

> Instead of all of this, let's just make the strong guarantee that if an object
> is transitively reachable from a local variable that is currently in scope
> (according to the bytecode's LVT), then the end of that scope happens before the
> execution of the finalizer.  Maybe we need to make certain guarantees about
> other GC roots, too (although I'm not sure exactly which - it seems as if the
> class unloading semantics take care of most of them).  Then we forget about this
> topic forever.

I like this proposal for the same reasons I like anything that could
allow us to get rid of rules that people don't understand, don't
follow, and/or don't believe.  (Although it is not as attractive as a
proposal to just deprecate method finalize, but we probably could
not get away with that.)

But I don't yet see a path to victory.  Take a look at the
(surprisingly long) JLS section (12.6) on finalization

The reachabilityFence (aka keepAlive) approach seems easy to state by
adding an item (about invocation of method reachabilityFence) to the
first bullet list of sec 12.6.2 ("The only objects that are considered
definitely reachable at a point di are those that can be shown to be
reachable by the application of these rules:...").  Disclaimer: I
don't know who wrote or last edited sec 12.6.2, and haven't tried to
fully sanity check it or ensure that it would still make sense with
this change.

I'm not sure where to start with the automatic approach.  Without
care, this may end up causing fewer but even more subtle and
undebuggable errors.  One approach is to imagine a tool that
automatically inserts reachabilityFence calls, make sure all cases are
covered, and then try to explain what it does?  Short of that, I'm led
to the wimpy position that if we at least provide reachabilityFence
itself, others can/will build tools to insert or check them, and we
can claim modest success?


More information about the jmm-dev mailing list