Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of oliver.deakin@googlemail.com
 designates 209.85.215.49 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=fxM2jc1Ur/WXrbmu8u9yHKr2iXKQygGOqaKo6demxCKVjKTx42SeWW5aYx5QOvdeTa
         X86i4tGxRtAZJavk7fovdO56b5Pp9tlDMi1IkDkp7eE5BZwAZFHs4QnZBY5noGmkHUsU
         q7cMKG6y9P4g1Ip4oH1r9O5+oaQl1sPr88ctg=
Message-ID: <4C6918B1.8060301@googlemail.com>
Date: Mon, 16 Aug 2010 11:53:37 +0100
From: Oliver Deakin <oliver.deakin@googlemail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [drlvm] Should the referent of a PhantomReference be cleared
 before it is enqueued?
References: <4C62DB1D.1060803@googlemail.com>
 <AANLkTimjy0ZJ0g9ULbSXVic95jeZyOSzC6Weroa8tadb@mail.gmail.com>
In-Reply-To: <AANLkTimjy0ZJ0g9ULbSXVic95jeZyOSzC6Weroa8tadb@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

  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.deakin@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