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.
Posted Date : 2009-07-27 07:47:06.0

N/A

The problem at the same place as in 6851282.
The new Phi narrow type is incorrect for the next case since it is based on the type of one of inputs
which could be subtype:

 2910   ConN    ===  0  [[ 2854 ]]  #narrowoop: precise klass DoubletonList: 0x00000000008101f8:Constant:exact *
 2911   ConN    ===  0  [[ 2853 ]]  #narrowoop: precise klass SingletonList: 0x0000000000810118:Constant:exact *
 2854   DecodeN === _  2910  [[ 2869 ]]  #klass AbstractMemoryEfficientList: 0x00000000008546b8 *  Klass:klass AbstractMemoryEfficientList: 0x00000000008546b8 * !orig=[1876] !jvms: AbstractMemoryEfficientList::equals @ bci:53 AbstractList::equals @ bci:-1
 2853   DecodeN === _  2911  [[ 2869 ]]  #klass AbstractMemoryEfficientList: 0x00000000008546b8 *  Klass:klass AbstractMemoryEfficientList: 0x00000000008546b8 * !orig=[1876] !jvms: AbstractMemoryEfficientList::equals @ bci:53 AbstractList::equals @ bci:-1
 2869   Phi     ===  2862  2853  2854  [[ 2858  2856 ]]  #klass AbstractMemoryEfficientList: 0x00000000008546b8 *  Klass:klass AbstractMemoryEfficientList: 0x00000000008546b8 * !orig=[2852],[1876] !jvms: AbstractMemoryEfficientList::equals @ bci:53 AbstractList::equals @ bci:-1

After the optimization in PhiNode::Ideal we will get new Phi with incorrect type:

 2910   ConN    ===  0  [[ 2854  2916 ]]  #narrowoop: precise klass DoubletonList: 0x00000000008101f8:Constant:exact *
 2911   ConN    ===  0  [[ 2853  2916 ]]  #narrowoop: precise klass SingletonList: 0x0000000000810118:Constant:exact *
  2916   Phi     ===  2862  2911  2910  [[ 2917 ]]  #narrowoop: precise klass DoubletonList: 0x00000000008101f8:Constant:exact * !orig=2869,[2852],[1876] !jvms: AbstractMemoryEfficientList::equals @ bci:53 AbstractList::equals @ bci:-1

The Phi is used in Cmp node and as result of wrong type the result of Cmp is wrong. It leads to incorrect graph and generated code.
Posted Date : 2009-07-30 02:27:40.0

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/55cb84cd1247
Posted Date : 2009-07-31 23:05:59.0

http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/55cb84cd1247
Posted Date : 2009-08-10 07:36:29.0

When looking at the generated opto assembly in the failing case you can clearly see the problem. Here is a bit of the x86 code that is generated when AbstractMemoryEfficientList.equals() gets inlined into AbstraceList.equals().


8b5   B72: #    B73 <- B69  Freq: 0.0675861
8b5     # checkcastPP of RBP
8b5     movq    [rsp + #48], RBP        # spill
8ba     movq    R10, [rsp + #40]        # spill
8bf     movl    RCX, [R10 + #12 (8-bit)]        # compressed ptr ! Field DoubletonList.element1
8c3     movl    RBX, [R10 + #16 (8-bit)]        # compressed ptr ! Field DoubletonList.element2
8c7     xorl    R10, R10        # int
8ca
8ca   B73: #    B109 B74 <- B72 B98     Loop: B73-B98 stride: not constant  Freq: 0.153171
8ca     cmpl    R10, #1
8ce     jne     B109  P=0.500000 C=-1.000000
8ce
8d4   B74: #    B75 <- B73  Freq: 0.0765857
8d4     movl    [rsp + #20], RBX        # spill
8d4
8d8   B75: #    B176 B76 <- B74 B111  Freq: 0.153171
8d8     movq    RBP, [rsp + #48]        # spill
8dd     # checkcastPP of RBP
8dd     testl   R10, R10
8e0     jne     B176  P=0.000000 C=6048.000000

.. Code elided

be7   B98: #    B73 B99 <- B78 B130 B97 B108  Freq: 0.137781
be7     incl    R10     # int
bea     cmpl    R10, #2
bee     jl     B73      # loop end  P=0.621168 C=8814.000000


Note at 8ca that R10 (the value of “i” in the loop in AbstractMemoryEfficientList.equals()) is tested for being 1. If it is 1 (which it can be) then it passes through the test and falls into block B75. This block then compares “i” to zero and if it isn’t zero (which it isn’t because it’s 1) then it jumps to block B176.

1a11   B176: #  N2317 <- B75  Freq: 7.65856e-08
1a11    movl    RSI, #3 # int
1a16    movl    [rsp + #12], R10        # spill
1a1b    call,static  wrapper for: uncommon_trap(reason='unloaded' action='reinterpret' index='3')
        # SingletonList::get @ bci:9  L[0]=RBP L[1]=rsp + #12
        # AbstractMemoryEfficientList::equals @ bci:53  L[0]=rsp + #40 L[1]=_ L[2]=RBP L[3]=rsp + #12 L[4]=_ STK[0]=rsp + #20
        # java.util.AbstractList::equals @ bci:82  L[0]=_ L[1]=_ L[2]=rsp + #0 L[3]=rsp + #32 L[4]=_ L[5]=_
        # OopMap{rbp=Oop [0]=Oop [20]=NarrowOop [32]=Oop [40]=Oop off=6688}
1a20    int3    # ShouldNotReachHere

This throws an exception of the exact type you see above. 

It looks as though the "DoubletonList" case is getting mixed up with the "SingletonList" case.