harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Deakin <oliver.dea...@googlemail.com>
Subject Re: [classlib][testcase] should weakreference be queued in runFinalization()?
Date Mon, 16 Apr 2007 08:27:49 GMT
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


Mime
View raw message