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.


======================================================================