You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Oliver Deakin <ol...@googlemail.com> on 2010/08/11 19:17:17 UTC
[drlvm] Should the referent of a PhantomReference be cleared before
it is enqueued?
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
Re: [drlvm] Should the referent of a PhantomReference be cleared
before it is enqueued?
Posted by Oliver Deakin <ol...@googlemail.com>.
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<ol...@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
Re: [drlvm] Should the referent of a PhantomReference be cleared
before it is enqueued?
Posted by Deven You <de...@gmail.com>.
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 <ol...@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
>
>