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
