Vladimir, I've committed your patch. Thanks for the prompt action. -xiaofeng
On 5/24/07, Vladimir Ivanov <[EMAIL PROTECTED]> wrote:
issue 3917 was updated (exclude lists were changed). Thanks, Vladimir On 5/23/07, Xiao-Feng Li <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > Xiao-Feng Li wrote: > > > On 4/13/07, Oliver Deakin <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > >> >> > > > >> >> > On 4/13/07, Oliver Deakin <[EMAIL PROTECTED]> 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
