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

Application gives bad result (throws bad exception) with compressed oops

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: P3 P3
    • hs16
    • 6u14, 6u14p
    • hotspot
    • b08
    • generic, x86
    • generic, linux, solaris_10
    • Verified

        FULL PRODUCT VERSION :
        java 6 update 14

        FULL OS VERSION :
        Linux RHEL 5

        A DESCRIPTION OF THE PROBLEM :
        While testing the -XX:+UseCompressedOops option with 6u14, we found that one of our applications started giving bad results and incorrect runtime behaviour. We have reduced this to a test case. The problem doesn't happen if you run without the -XX:+UseCompressedOops flag but that flag is the major driver for moving to this release.

        Note that this is *not* the same problem as http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6851282. We tried retrofitting that fix into the 6u14 source base and building a local libjvm.so. Although it fixes the test case in that bug report, we still get the same intermittent exception.

        THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: No

        THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Yes

        STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
        Compile and run the attached code.

        I run it as

        java -XX:+UseCompressedOops hello goodbye

        EXPECTED VERSUS ACTUAL BEHAVIOR :
        It should just return normally.

        About one time in five (although it varies so you might need to run it more often to make it happen) it crashes with a stack trace. The stack trace is obviously wrong because it shows that the "this" and the argument are both instances of DoubletonList, but the class being accessed is an instance of SingletonList.

        Here is the output:

        THROWING RT EXC
        concurrent modification of this:class DoubletonList:1414159026; that:class DoubletonList:1569228633; i:1
        java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
         23 at SingletonList.get(ToS.java:74)
               WeakPool:: at AbstractMemoryEfficientList.equals(ToS.java:34)
        ge at java.util.AbstractList.equals(AbstractList.java:507)
        tTable (9 bytes)
                at MultiSynonymKey.equals(ToS.java:544)
                at WeakPool.eq(ToS.java:154)
                at WeakPool.put(ToS.java:307)
                at ToS.main(ToS.java:607)

        As you can see, both "this" and the input arg are instances of DoubletonList but the stack trace shows that SingletonList.get() has been called.
        ERROR MESSAGES/STACK TRACES THAT OCCUR :
        THROWING RT EXC
        concurrent modification of this:class DoubletonList:1414159026; that:class DoubletonList:1569228633; i:1
        java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
         23 at SingletonList.get(ToS.java:74)
               WeakPool:: at AbstractMemoryEfficientList.equals(ToS.java:34)
        ge at java.util.AbstractList.equals(AbstractList.java:507)
        tTable (9 bytes)
                at MultiSynonymKey.equals(ToS.java:544)
                at WeakPool.eq(ToS.java:154)
                at WeakPool.put(ToS.java:307)
                at ToS.main(ToS.java:607)



        REPRODUCIBILITY :
        This bug can be reproduced occasionally.

        ---------- BEGIN SOURCE ----------
        Attached seperatly
        ---------- END SOURCE ----------

        CUSTOMER SUBMITTED WORKAROUND :
        Turn off -XX:+UseCompressedOops, but we only really are using 6u14 to get compressed oops.

              kvn Vladimir Kozlov
              ndcosta Nelson Dcosta (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: