Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4268317

(ref) Reference.isEnqueued() can return true when instance not enqueued

    XMLWordPrintable

    Details

    • Subcomponent:
    • Resolved In Build:
      b14
    • CPU:
      generic, x86, sparc
    • OS:
      generic, linux_suse_sles_10, solaris_2.6, solaris_7, windows_nt
    • Verification:
      Verified

      Backports

        Description

        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.


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

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                ysr Y. Ramakrishna
                Reporter:
                akuzminorcl Alexander Kuzmin (Inactive)
                Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: