Lightweight finalization for the JDK without any drawbacks was: Why is finalize wrong?

[Jaroslav Tulach]

Hello Doug,
thanks for your reply and clarification about finalization. May I ask for one more 
clarification, this time about WeakReference behavior?

There has been a claim made in this thread that an object which is "really gone" (from 
a point of view of WeakReference) may have its instance method being executed. 
Something like:

obj = new Object();
ref = new WeakReference<Object>(obj);
class OtherThread extends Thread {
  public void run() {
    obj.toString();
    obj = null;
  }
}
new OtherThread().start();
obj = null;
while (ref.get() != null) {
  // wait
}
assert ref.get() == null;
// can the OtherThread be calling toString() on obj now!?

>From my point of view, this is impossible. Once ref.get() returns null, the obj is no 
longer reachable and is "really gone". Would you be so kind and confirm this 
observation or is there a chance Andrew could be right?

On Aug 7 2014 Andrew Haley wrote:
> It's not a bug: it's in the specification, has been since 1996.

Given the fact that WeakReference & co. has been introduced in JDK 1.2 and that 
version was released at the end of 1998, I bet it was just a communication problem, as 
Andrew must have been talking about something else than WeakReference + 
ReferenceQueue behavior.

-jt


> On 08/07/2014 03:43 AM, Jaroslav Tulach wrote:
> > Dne Čt 7. srpna 2014 08:17:16, Andrew Haley napsal(a):
> >> I'm wondering whether it's really worth your time applying band-aids to
> >> a broken mechanism.
> > 
> > Under the assumption WeakReference and ReferenceQueue are flawless, there
> > is no reason to call a mechanism based on WeakReference and
> > ReferenceQueue synergy "broken".
> > 
> >> An object can be
> >> "really gone" even when one of its instance methods is still executing.
> > 
> > That would probably signal a major flaw in the JVM.
> 
> Finalization is not broken in the sense of not meeting its specs
> (see http://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.6)
> but some surprising and undesirable cases are allowed,
> and actually occur, in highly concurrent programs.
> Including cases where finalizers may run concurrently with
> the final invocation of a method on the target.
> Because the specs interact with the details of the memory model,
> we have been discussing (on jmm-dev list) possible changes
> and  improvements. But in the mean time (or in any case), the best
> practice is to consider finalization as a last resort, after
> ruling out all other possible cleanup strategies.
> Finalization is easy to spec, implement, and control in
> purely sequential systems, but is a questionable idea in
> concurrent ones.
> 
> -Doug

Dne Čt 7. srpna 2014 16:50:39, Andrew Haley napsal(a):
> On 07/08/14 08:43, Jaroslav Tulach wrote:
> >> > On 06/08/14 11:17, Jaroslav Tulach wrote:
> >>> > > Sure, but that cannot happen with activeQueue() as the referent is
> >>> > > really
> >>> > > gone before appropriate Reference.run() is executed.
> >> > 
> >> > I'm sure that it can happen, in just the same way.
> > 
> > You are more than welcomed to prove your claim and report bug to JDK. I'd
> > say.
> It's not a bug: it's in the specification, has been since 1996.
> 
> Andrew.