Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of xiaofeng.li@gmail.com
 designates 66.249.82.232 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=MXDOMKMIAxjEZbGBBowNftfgBJhU4CwlJtg2Vj0UD9K/ItSPY/XuSQpO+iUn6V/QCSFoB+df2BnnCi1ENDiDgw8CezNSGfnzRx3ZXUGswiMw/T03HF6fB2Mz8g/xqKKJUb1KPXJ69QszUVqMjCY9uJUHlMBJkGkyzT4ii7vIikE=
Message-ID: <9623c9a50705232231h83e01f1s49fe9ca082a6a532@mail.gmail.com>
Date: Thu, 24 May 2007 13:31:20 +0800
From: "Xiao-Feng Li" <xiaofeng.li@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [drlvm][test] should weakreference be queued in
 runFinalization()?
In-Reply-To: <7273946b0705232138p78acb659x280d6a0feffd8556@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <9623c9a50704121937w56c8f045t35fba03ac80f2d59@mail.gmail.com>
	 <461F4428.8000109@googlemail.com>
	 <9623c9a50704130204x207134ffrf81f56eac5f24eee@mail.gmail.com>
	 <e66844de0704130222x1d72123eh7d0039736271038b@mail.gmail.com>
	 <9623c9a50704130641m15575605n9096135ec7ec70ae@mail.gmail.com>
	 <461FA773.10502@googlemail.com>
	 <9623c9a50704131906w46c3d478r1bc9c962fdd79119@mail.gmail.com>
	 <46233385.1080902@googlemail.com>
	 <9623c9a50705230853p594bd4ddp2cd9c36d057ae057@mail.gmail.com>
	 <7273946b0705232138p78acb659x280d6a0feffd8556@mail.gmail.com>

Vladimir, I've committed your patch. Thanks for the prompt action. -xiaofeng

On 5/24/07, Vladimir Ivanov <ivavladimir@gmail.com> wrote:
> issue 3917 was updated (exclude lists were changed).
>
>  Thanks, Vladimir
>
> On 5/23/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> > Hi, I am bringing this topic back again but with a different subject. :-)
> >
> > As we discussed in this thread, I'd propose to exclude the tests:
> > gc.PhantomReferenceTest and gc.WeakReferenceTest.
> > This issue is filed in https://issues.apache.org/jira/browse/HARMONY-3917.
> >
> > Vladimir Ivanov, would you please help to exclude these two tests (I
> > assume no objects here)?
> >
> > Thanks,
> > xiaofeng
> >
> >
> > On 4/16/07, Oliver Deakin <oliver.deakin@googlemail.com> wrote:
> > > Xiao-Feng Li wrote:
> > > > On 4/13/07, Oliver Deakin <oliver.deakin@googlemail.com> wrote:
> > > >> The other way I can think of to force a gc, and thus hopefully have the
> > > >> weak reference cleared, is to do the following:
> > > >>  - restrict heap size to a very small amount when launching the VM.
> > > >>  - create WeakReference object and its referent.
> > > >>  - fill heap with dummy objects until OutOfMemory is achieved (at which
> > > >> point you should be able to assume that at least one gc has occured, as
> > > >> it is unlikely that the memory manager will not have gc'ed at all before
> > > >> giving OOM).
> > > >>  - free up dummy objects and check WeakReference.
> > > >>
> > > >> IMO it's a pretty ugly way to test this, but perhaps it's the only way
> > > >> to make sure that a gc really does occur.
> > > >
> > > > Yes, this can sort of ensure a GC. But it still doesn't guarantee the
> > > > weakrefs are enqueued. Since weakrefs are usually enqueued in a
> > > > seperate thread after GC identifies their referents are unreachable
> > > > strongly, we cannot have a time expectation on how fast this thread
> > > > can finish all the enqueuing operations. Maybe the test can loop over
> > > > to check the queue wishing to get the weakref from it within certain
> > > > period, say 1 second. The loop body should have a thread yield after
> > > > every check to give processor time to the enqueuing thread.
> > >
> > > Yes that's true - if gc does occur we still cannot guarantee that the
> > > weakref gets enqueued. Even with a loop and a wait as you suggest, I do
> > > not see this being a 100% reliable test. Unfortunately I cannot imagine
> > > any test scenario where we can consistently get accurate results from a
> > > test of weakrefs - although we can increase our chances of getting a
> > > true result using the method you describe. However, if we know that this
> > > test could still intermittently fail falsely, should we run it at all?
> > >
> > > Regards,
> > > Oliver
> > >
> > > >
> > > >
> > > > Thanks,
> > > > xiaofeng
> > > >
> > > >> Regards,
> > > >> Oliver
> > > >>
> > > >> Xiao-Feng Li wrote:
> > > >> > On 4/13/07, Leo Li <liyilei1979@gmail.com> wrote:
> > > >> >>  I think it assured that the reference is eventually enqueued. So
> > > >> is it
> > > >> >> possible to test it before VM shutdown by means of JVMTI? (But I am
> > > >> >> not sure
> > > >> >> whether it is too late to get VM work properly.)
> > > >> >
> > > >> > It probably can't be tested just like you never know an object is
> > > >> > reclaimed.
> > > >> >
> > > >> > Thanks,
> > > >> > xiaofeng
> > > >> >
> > > >> >> On 4/13/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> > > >> >> >
> > > >> >> > On 4/13/07, Oliver Deakin <oliver.deakin@googlemail.com> wrote:
> > > >> >> > > The 5.0 spec for runFinalization() says:
> > > >> >> > >
> > > >> >> > > "Calling this method suggests that the Java Virtual Machine
> > > >> expend
> > > >> >> > > effort toward running the finalize methods of objects that
> > > >> have been
> > > >> >> > > found to be discarded but whose finalize methods have not yet
> > > >> >> been run."
> > > >> >> > >
> > > >> >> > > and for gc():
> > > >> >> > >
> > > >> >> > > "Calling the gc method suggests that the Java Virtual Machine
> > > >> expend
> > > >> >> > > effort toward recycling unused objects"
> > > >> >> > >
> > > >> >> > > The key word in both those specs is /suggests/. There is *no*
> > > >> >> guarantee
> > > >> >> > > that any finalizers are run or that a gc actually occurs when
> > > >> these
> > > >> >> > > calls are made - it is only a hint to the VM.
> > > >> >> > >
> > > >> >> > > If a test is expecting these calls to definitely gc and run
> > > >> >> finalizers,
> > > >> >> > > then IMO the test is in error.
> > > >> >> >
> > > >> >> > Yes, I have the seem opinion. And both gc() and runFinalization()
> > > >> >> > actually say nothing about weakreference. Don't know why they
> > > >> are used
> > > >> >> > to test References.
> > > >> >> >
> > > >> >> > Thanks,
> > > >> >> > xiaofeng
> > > >> >> >
> > > >> >> > > Regards,
> > > >> >> > > Oliver
> > > >> >> > >
> > > >> >> > >
> > > >> >> > > Xiao-Feng Li wrote:
> > > >> >> > > > In classlib tests "gc.PhantomReferenceTest" and
> > > >> >> > > > "tests.api.java.lang.ref.ReferenceTest", they expect
> > > >> weakreference
> > > >> >> > > > objects be queued after System.runFinalization(). Is this
> > > >> >> correct? In
> > > >> >> > > > my understanding of the spec, there is no requirement on this
> > > >> >> > > > behavior.
> > > >> >> > > >
> > > >> >> > > > The tests do like this:
> > > >> >> > > >
> > > >> >> > > > =========================
> > > >> >> > > > //wr is the weakreference, whose referent is only weakly
> > > >> >> reachable.
> > > >> >> > > > //rq is the reference queue
> > > >> >> > > >
> > > >> >> > > > System.gc();
> > > >> >> > > > System.runFinalization();
> > > >> >> > > >
> > > >> >> > > > ref = rq.poll();
> > > >> >> > > >
> > > >> >> > > > assertTrue("Unexpected ref2", ref == wr);
> > > >> >> > > > assertNotNull("Object not garbage collected.", ref);
> > > >> >> > > > assertNull("Object could not be reclaimed.", ref.get());
> > > >> >> > > > =========================
> > > >> >> > > >
> > > >> >> > > > After runFinalization(), it requires the queue has the
> > > >> >> weakreference.
> > > >> >> > > > Actually it has requirement on System.gc() as well, requiring
> > > >> >> it to
> > > >> >> > > > identify the weakly reachable object accurately.
> > > >> >> > > >
> > > >> >> > > > In my understanding of the spec, this kind of tests are
> > > >> wrong. It
> > > >> >> > > > forces the GC to do something not required by spec.
> > > >> >> > > >
> > > >> >> > > > How do you think?
> > > >> >> > > >
> > > >> >> > > > Thanks,
> > > >> >> > > > xiaofeng
> > > >> >> > > >
> > > >> >> > >
> > > >> >> > > --
> > > >> >> > > 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
> > > >>
> > > >>
> > > >
> > > >
> > >
> > > --
> > > 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
> > >
> > >
> >
> >
> > --
> > http://xiao-feng.blogspot.com
> >
>


-- 
http://xiao-feng.blogspot.com