Hi Jaroslav,
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.
Stanimir
On Fri, Aug 8, 2014 at 11:01 AM, Jaroslav Tulach <jaroslav.tul...@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.
> > It's not a bug: it's in the specification, has been since 1996.
> >
> > Andrew.
>
>
