You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Xiao-Feng Li <xi...@gmail.com> on 2007/04/13 04:37:14 UTC
[classlib][testcase] should weakreference be queued in runFinalization()?
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
Re: [classlib][testcase] should weakreference be queued in runFinalization()?
Posted by Leo Li <li...@gmail.com>.
Hi, Xiao-Feng:
You are right. Java does not assure the postmortem events, not like
the deconstructor in C#. :)
On 4/13/07, Xiao-Feng Li <xi...@gmail.com> wrote:
>
> On 4/13/07, Leo Li <li...@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 <xi...@gmail.com> wrote:
> > >
> > > On 4/13/07, Oliver Deakin <ol...@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
> > > >
> > > >
> > >
> > >
>
--
Leo Li
China Software Development Lab, IBM
Re: [drlvm][test] should weakreference be queued in runFinalization()?
Posted by Rana Dasgupta <rd...@gmail.com>.
+1
It makes sense to remove both
On 5/23/07, Xiao-Feng Li <xi...@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 <ol...@googlemail.com> wrote:
> > Xiao-Feng Li wrote:
> > > On 4/13/07, Oliver Deakin <ol...@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 <li...@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 <xi...@gmail.com> wrote:
> > >> >> >
> > >> >> > On 4/13/07, Oliver Deakin <ol...@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
>
Re: [drlvm][test] should weakreference be queued in runFinalization()?
Posted by Xiao-Feng Li <xi...@gmail.com>.
Vladimir, I've committed your patch. Thanks for the prompt action. -xiaofeng
On 5/24/07, Vladimir Ivanov <iv...@gmail.com> wrote:
> issue 3917 was updated (exclude lists were changed).
>
> Thanks, Vladimir
>
> On 5/23/07, Xiao-Feng Li <xi...@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 <ol...@googlemail.com> wrote:
> > > Xiao-Feng Li wrote:
> > > > On 4/13/07, Oliver Deakin <ol...@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 <li...@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 <xi...@gmail.com> wrote:
> > > >> >> >
> > > >> >> > On 4/13/07, Oliver Deakin <ol...@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
Re: [drlvm][test] should weakreference be queued in runFinalization()?
Posted by Vladimir Ivanov <iv...@gmail.com>.
issue 3917 was updated (exclude lists were changed).
Thanks, Vladimir
On 5/23/07, Xiao-Feng Li <xi...@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 <ol...@googlemail.com> wrote:
> > Xiao-Feng Li wrote:
> > > On 4/13/07, Oliver Deakin <ol...@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 <li...@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 <xi...@gmail.com> wrote:
> > >> >> >
> > >> >> > On 4/13/07, Oliver Deakin <ol...@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
>
[drlvm][test] should weakreference be queued in runFinalization()?
Posted by Xiao-Feng Li <xi...@gmail.com>.
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 <ol...@googlemail.com> wrote:
> Xiao-Feng Li wrote:
> > On 4/13/07, Oliver Deakin <ol...@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 <li...@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 <xi...@gmail.com> wrote:
> >> >> >
> >> >> > On 4/13/07, Oliver Deakin <ol...@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
Re: [classlib][testcase] should weakreference be queued in runFinalization()?
Posted by Oliver Deakin <ol...@googlemail.com>.
Xiao-Feng Li wrote:
> On 4/13/07, Oliver Deakin <ol...@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 <li...@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 <xi...@gmail.com> wrote:
>> >> >
>> >> > On 4/13/07, Oliver Deakin <ol...@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
Re: [classlib][testcase] should weakreference be queued in runFinalization()?
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 4/13/07, Oliver Deakin <ol...@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.
Thanks,
xiaofeng
> Regards,
> Oliver
>
> Xiao-Feng Li wrote:
> > On 4/13/07, Leo Li <li...@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 <xi...@gmail.com> wrote:
> >> >
> >> > On 4/13/07, Oliver Deakin <ol...@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
>
>
--
http://xiao-feng.blogspot.com
Re: [classlib][testcase] should weakreference be queued in runFinalization()?
Posted by Oliver Deakin <ol...@googlemail.com>.
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.
Regards,
Oliver
Xiao-Feng Li wrote:
> On 4/13/07, Leo Li <li...@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 <xi...@gmail.com> wrote:
>> >
>> > On 4/13/07, Oliver Deakin <ol...@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
Re: [classlib][testcase] should weakreference be queued in runFinalization()?
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 4/13/07, Leo Li <li...@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 <xi...@gmail.com> wrote:
> >
> > On 4/13/07, Oliver Deakin <ol...@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
> > >
> > >
> >
> >
Re: [classlib][testcase] should weakreference be queued in runFinalization()?
Posted by Leo Li <li...@gmail.com>.
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.)
On 4/13/07, Xiao-Feng Li <xi...@gmail.com> wrote:
>
> On 4/13/07, Oliver Deakin <ol...@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
> >
> >
>
>
> --
> http://xiao-feng.blogspot.com
>
--
Leo Li
China Software Development Lab, IBM
Re: [classlib][testcase] should weakreference be queued in runFinalization()?
Posted by Oliver Deakin <ol...@googlemail.com>.
I can see what the tester was expecting - if a gc is definitely run, you
might expect that the weak reference would be cleared. However, it is
slightly more subtle than that since:
- gc might not actually be run by the gc() call.
- the gc might not necessarily determine that the object is weakly
reachable in its first pass.
References are a very difficult area to test reliably precisely because
of the non-committal nature of the spec on the gc() and runFnializers()
methods. Any improvements or innovative approaches you can think of for
these tests would be good! In it's current state, this test looks invalid.
Regards,
Oliver
Xiao-Feng Li wrote:
> On 4/13/07, Oliver Deakin <ol...@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
Re: [classlib][testcase] should weakreference be queued in runFinalization()?
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 4/13/07, Oliver Deakin <ol...@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
>
>
--
http://xiao-feng.blogspot.com
Re: [classlib][testcase] should weakreference be queued in runFinalization()?
Posted by Oliver Deakin <ol...@googlemail.com>.
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.
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