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

[Jaroslav Tulach]

Dne Pá 8. srpna 2014 15:02:41, Stanimir Simeonoff napsal(a):
> The snippet is likely to just result into a NPE at obj.toString() than
> anything else as "obj" must be a member and volatile to even compile.

Well, it is just pseudo-code. Please notice that variables don't even have right types. 
My primary question was whether toString() can be on stack while ref.get() returns 
null.

According to articles provided by Andrew[1], toString() can be on stack, even if obj 
(e.g. this for toString()) is garbage collected. This is a bit surprising (an OOP fan 
would expect that this is GC root while its instance method is running), but such 
behavior is said to be in accordance to the 1.8 spec.

Question for Doug (as a member of jmm-dev list) then is: would not it be wise to 
change the spec to require this to be GC root while its instance method is being 
executed?

-jt

> 
> On Fri, Aug 8, 2014 at 11:01 AM, Jaroslav Tulach <jaroslav.tulach at oracle.com
> > wrote:
> > 
> > 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.
> > >