harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Ivanov" <ivavladi...@gmail.com>
Subject Re: [drlvm][test] should weakreference be queued in runFinalization()?
Date Thu, 24 May 2007 04:38:14 GMT
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
>

Mime
View raw message