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.
