Duplicate :
|
|
Duplicate :
|
|
Duplicate :
|
|
Relates :
|
|
Relates :
|
The JCK13 test api/java_lang/ref/WeakReference/index.html#WeakReference0600 failed in the build (JDK1.3-"O" was used) JTR file: #Test Results (version 2) #Wed Sep 01 23:04:48 PDT 1999 #-----testdescription----- executeArgs=-TestCaseID ALL executeClass=javasoft.sqe.tests.api.java.lang.ref.WeakReference.GCEnqueueingTests file=/opt/build13/jck13-tests-build/unzip/JCK-runtime-13beta/tests/api/java_lang/ref/WeakReference/index.html id=WeakReference0600 keywords=api positive runtime source=GCEnqueueingTests.java testsuite=/opt/build13/jck13-tests-build/unzip/JCK-runtime-13beta/tests timeout=3000 title=WeakReference GC enqueueing #-----testresult----- description=file:/opt/build13/jck13-tests-build/unzip/JCK-runtime-13beta/tests/api/java_lang/ref/WeakReference/index.html#WeakReference0600 end=Wed Sep 01 23:04:48 PDT 1999 environment=jck-runtime-solaris execStatus=Failed. tests: 7; passed: 5; failed: 2; first test case failure: WeakReference0603 javatestVersion=JT_2.1k script=javasoft.sqe.javatest.lib.JCKScript -runtime sections=script_messages testExecute start=Wed Sep 01 23:04:46 PDT 1999 status=Failed. tests: 7; passed: 5; failed: 2; first test case failure: WeakReference0603 test=api/java_lang/ref/WeakReference/index.html#WeakReference0600 timeoutSeconds=3000 work=/opt/build13/jck13-tests-build/test/JCK-runtime-13beta/runtime-batch-multiJVM-jit-native/work/api/java_lang/ref/WeakReference #section:script_messages ----------messages:(1/24)---------- Executing test class... #section:testExecute ----------messages:(1/566)---------- command: javasoft.sqe.javatest.lib.ExecJCKTestOtherJVMCmd CLASSPATH=/opt/build13/jck13-tests-build/unzip/JCK-runtime-13beta/tests/../classes:/opt/build13/jck13-tests-build/unzip/JCK-runtime-13beta/javatest.jar DISPLAY=novo35:0.0 HOME=/home/kuzm LD_LIBRARY_PATH=/opt/build13/jck13-tests-build/unzip/JCK-runtime-13beta/tests/../lib /opt/build13/jdk1.3/O/solaris/bin/java -Xfuture -Djava.security.policy=/opt/build13/jck13-tests-build/unzip/JCK-runtime-13beta/tests/../lib/jck.policy javasoft.sqe.tests.api.java.lang.ref.WeakReference.GCEnqueueingTests -TestCaseID ALL ----------ref:(0/0)---------- ----------log:(9/406)---------- args decoded WeakReference0601: Passed. OKAY WeakReference0602: Passed. OKAY WeakReference0603: Failed. WeakRef(obj, queue): after GC enqueueing enqueue()==true WeakReference0604: Failed. after GC enqueueing poll()==null WeakReference0605: Passed. OKAY WeakReference0606: Passed. OKAY WeakReference0607: Passed. OKAY STATUS:Failed.tests: 7; passed: 5; failed: 2; first test case failure: WeakReference0603 result: Failed. tests: 7; passed: 5; failed: 2; first test case failure: WeakReference0603 test result: Failed. tests: 7; passed: 5; failed: 2; first test case failure: WeakReference0603 Name: akC45999 Date: 09/06/99 After GC enqueues WeakReference created with queue the methods enqueue() and poll() sometimes return wrong values. Java Platform 1.3 API Specification says: "Suppose that the garbage collector determines at a certain point in time that an object is weakly reachable. At that time it will atomically clear all weak references to that object ... At the same time or at some later time it will enqueue those newly-cleared weak references that are registered with reference queues." According to the specification after GC enqueues the WeakReference object created with queue (i.e. isEnqueued() returns true) the method enqueue() should return false. The method poll() applied to the queue in turn should return WeakReference object enqueued. But the following code shows that sometimes enqueue() returns true and poll() returns null. The bug appears in JDK1.3-"M", JDK1.3-"N", JDK1.3-"O" - only on Sparc, HotSpot VM. novo81% java -version java version "1.3beta" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3beta-O) Java(TM) HotSpot Client VM (build 1.3beta-O-release, 1.3beta-O-release, interpreted mode) novo81% java WeakRef WRONG: enqueue() returned true instead of false OKAY novo81% java WeakRef WRONG: enqueue() returned true instead of false WRONG: poll() returned null instead of refWeak enqueued novo81% ------------------------------------------------------------------ import java.lang.ref.*; public class WeakRef { public static void main(String args[]){ WeakRef1(); WeakRef2(); } //the method enqueue() returns wrong value public static void WeakRef1() { ReferenceQueue queue = new ReferenceQueue(); WeakReference refWeak = new WeakReference(new Object(), queue); System.gc(); long startTime = System.currentTimeMillis(); while (System.currentTimeMillis() < (startTime + 100000)) { System.gc(); if (refWeak.isEnqueued() == false) { try { Thread.sleep(100); } catch (InterruptedException i) { } continue; } break; } if (refWeak.isEnqueued() == false) { // OKAY, GC have not enqueued refWeak for the timeout period System.out.println("OKAY"); return; } if (refWeak.enqueue() == true) { // not OKAY, enqueue() should return false since // refWeak is already enqueued by the GC System.out.println("WRONG: enqueue() returned true " + "instead of false"); return; } System.out.println("OKAY"); return; } //the method poll() returns wrong value public static void WeakRef2() { ReferenceQueue queue = new ReferenceQueue(); WeakReference refWeak = new WeakReference(new Object(), queue); System.gc(); long startTime = System.currentTimeMillis(); while (System.currentTimeMillis() < (startTime + 100000)) { System.gc(); if (refWeak.isEnqueued() == false) { try { Thread.sleep(100); } catch (InterruptedException i) { } continue; } break; } if (refWeak.isEnqueued() == false) { //OKAY, GC have not enqueued refWeak for the timeout period System.out.println("OKAY"); return; } if (queue.poll() == null) { //not OKAY, poll() should return refWeak enqueued by the GC System.out.println("WRONG: poll() returned null instead " + "of refWeak enqueued"); return; } System.out.println("OKAY"); return; } }//end of class WeakRef -------------------------------------------------------------------------- ====================================================================== The exact same problem occurs with phantom and (likely) soft references. -- mr@eng 1999/9/16 Name: ks88420 Date: 09/19/2000 java version "1.3.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C) Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode) The garbage collection within JDK1.3 is erratic when using Windows L&F, but predictable with Metal L&F. No tests have been done using Motif but similar problems may exist. Garbage collection problems can be easily demonstrated using the the Internal Frame demo from the Java Tutorial, within the section 'How To Use Internal Frames' (comprising the InternalFrameDemo.java and MyInternalFrame.java source files), run the example. Modify the example so that the L&F selected Windows, by inserting the line: UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName())at the start of the main method (appropriate try/catch also required). Running the example using OptimizeIt, open several JInternalFrames using the pull down menu and then close them. Select the pull down menu once more but do not select an item (this is just to discard the focus retained by Swing to the last JInternalFrame that was closed). Perform 2 GCs using OptimizeIt. Note that not all MyInternalFrame instances are GCd all of the time. Repeating the test shows the number of MyInternalFrame instances remaining varies. Now run the same example using Metal rather than Motif. All MyInternalFrame instances are always GCd after the second GC, all of the time. Examing the problem with OptimizeIt would seem to indicate that some references within the JInternalFrame's system menu are preventing GC (some of the time). I have experienced the GC not garbage collection some objects in my current project where there are a bunch of objects referencing each other but which are not referenced by any roots. As such they should be candidates for GC (assuming a mark and sweep technique to perform the GC). The JInternalFrame demo does highlight this problem in a simplistic scenario. I appreciate that there are no requirement specified for the behaviour of GC within the VM spec (a fact I find utter madness), but even the Swing internals aren't being correctly GCd. Please don't just blow this problem off as not repeatable - it needs to be fixed. I don't see how the JDK1.3 release can be commercially viable given its current GC problems. I have yet to see any Java app of any reasonable size running and not constantly using more and more memory for no apparent reason. This problem needs to be addressed ASAP. Email me if you require any additional info. (Review ID: 106708) ====================================================================== Name: ooR10006 Date: 04/20/2001 Due to this bug the following tests fail since jdk1.4.0beta-b58: api/java_lang/ref/SoftReference/index.html#GCEnqueueing[SoftReference2020] api/java_lang/ref/SoftReference/index.html#GCEnqueueing[SoftReference2021] api/java_lang/ref/SoftReference/index.html#GCEnqueueing[SoftReference2022] ====================================================================== Name: ooR10006 Date: 11/25/2003 Also, the following testcases intermittently fail with jdk1.5 b28: api/java_lang/ref/PhantomReference/index.html#GCEnqueueing[PhantomReference2012] api/java_lang/ref/PhantomReference/index.html#GCEnqueueing[PhantomReference2013] api/java_lang/ref/PhantomReference/index.html#GCEnqueueing[PhantomReference2014] ====================================================================== Name: agR10195 Date: 01/25/2004 Alexey Gibadullin, ###@###.### Six tests from "testbase_vm" also fail because of that bug: gc/gctests/PhantomReference/phantom001 gc/gctests/PhantomReference/phantom002 gc/gctests/SoftReference/soft001 gc/gctests/SoftReference/soft002 gc/gctests/WeakReference/weak001 gc/gctests/WeakReference/weak002 The latest version of the testbase is located in /net/vmsqe.sfbay/export/backup/testbase/testbase_vm.1.5 I'm appending the tests' names to the description to exclude them from regular executions. ======================================================================
|