Agreed.
I tried some simple tests commenting out the line in the DRLVM code that
nulls the referent (looks to be line 400, finalizer_weakref.cpp). This
fixes the difference for one GC cycle, but we then crash in the next GC
cycle. I have a feeling that this is because the referent is actually
freed in the first cycle, but because we are no longer nulling the
reference from the PhantomReference the next GC cycle tries to free it
again and crashes.
I'm not sure whether just removing the code above this line that GCs the
referent (so it only gets GC'ed when it is completely unreachable rather
than phantomly reachable) will fix the crash - I'll take a bit more of a
look at it when I get time. If anyone has some knowledge of this code or
how to fix this issue it'd be a great help!
Regards,
Oliver
On 14/08/2010 11:39, Deven You wrote:
I agree with you.
> From my point, the spec means phantom references only be cleared by Java
code, GC won't clear them automatically. And GC only adds them into the
corresponding reference queue so that Java program can know the change and
decides whether or not clear these phantom references to make their
referents can be garbage collected.
2010/8/12 Oliver Deakin<oliver.dea...@googlemail.com>
I have discovered that DRLVM appears to clear the referent field of a
PhantomReference before calling its enqueue() method (this can be shown
quite easily by printing the referent field in Reference.enqueue()). This
behaviour appears to differ from the RI, on which a non-null referent can be
got hold of via reflection [1]. The spec for PhantomReference says:
"Unlike soft and weak references, phantom references are not automatically
cleared by the garbage collector as they are enqueued. An object that is
reachable via phantom references will remain so until all such references
are cleared or themselves become unreachable."
This reads to me that soft and weak references clear their referent field
before being enqueued, but phantom references should only make the referent
eligible for gc once the referent is no longer phantomly reachable (or
reachable at all). If this is the case, it would seem that DRLVM's current
behaviour does not match the spec.
Any comments/thoughts?
Regards,
Oliver
[1] An example of this kind of use/abuse of PhantomReference can be found
at:
http://www.roseindia.net/javatutorials/references.shtml
--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
