harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject [drlvm][test] should weakreference be queued in runFinalization()?
Date Wed, 23 May 2007 15:53:32 GMT
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

Mime
View raw message