[jmm-dev] Non-core-model issues status

[Hans Boehm]

Doug -

I don't really understand that claim.

It seems to be quite common to use finalization in classes that encapsulate
native objects, and use the Java object to deallocate the native one once
the Java one becomes unreachable.  There are reasons to use java.lang.ref
instead of finalization to avoid some of the problems associated with the
Java finalization design.  But that's irrelevant to this discussion;
java.lang.ref queues have the same issues, at least in the presence of more
than one thread.  Otherwise, I don't see a way around the use of
finalizers/java.lang.ref queues in cases like this.

And we seem to have lots of evidence that essentially everyone currently
gets this code wrong, introducing premature deallocations.  And I think
this canonical application is usually correct, except for this issue.
 Based on a small random sample of our code base, this, and the relatively
safe "warn if something leaked" idiom, are probably the dominant use case
for finalizers.

I agree that keepAlive would help, but all indications are that we would
still be left with lots of broken code, because people just don't
understand the problem.  This solution could essentially remove the runtime
cost associated with fixing the code, but the resulting code would still
look  very cluttered and ugly.  I'm also concerned about ease of use for
the annotation but, unlike keepAlive, it doesn't sound hopeless to me.  It
still seems to me it's worth exploring.

In my opinion, a lot of the web discussion of finalizers, including the
thread you cited, is badly flawed.  Java finalizers (unlike Modula 3/Xerox
Cedar finalizers) do have issues with ordering and the inability to
finalize an object more than once.  But those issues are largely fixed by
java.lang.ref, or can be worked around with finalize().  I think the
premature finalization issue we're talking about is the most serious
problem we have in this area.

Hans

On Saturday, September 6, 2014, Doug Lea <dl at cs.oswego.edu> wrote:

> On 09/02/2014 05:07 PM, Hans Boehm wrote:
>
>   > 2. We introduce and spec a reachabilityFence(Object x) method, and add
>>  > wording about it in JLS sec 12.6. Further suggestions for doing more
>>  > are still welcome. (Also, the method name is still up for grabs.
>>  > Except that the name "keepAlive" is known to be too confusing
>>  > to consider.)
>> I thought we were focusing primarily on an annotation to declare fields
>> that are
>> cleaned up by finalizers, so that accessing such fields inhibits
>> elimination of
>> "dead" references.  I continue to believe that an API call by itself will
>> not
>> fix the problem.
>>
>>
> Sorry for not being very consistent about this.
> The more I look into the practical problems people face using
> finalize, the less I believe that we can do anything that would
> lead anyone to ever recommend that people use it outside of a few
> niche contexts that already require lots of care and almost
> always involve synchronization patterns that avoid need for
> reachabilityFence/keepAlive. Still, reliance on coincidental
> properties of synchronize(x) seems like a too big of a flaw not
> to fix.
>
> See for example the core-libs-dev discussion going on among
> JDK and other library developers. Including:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-
> September/028479.html
> and follow-ups.
>
> -Doug
>
>