JDK-6616627 : 64-bit j2se build problem: ArrayIndexOutOfBoundsException: -2147483521
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2007-10-14
  • Updated: 2011-04-23
  • Resolved: 2011-04-23
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availabitlity Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u4Resolved 7Resolved hs10Resolved
Related Reports
Relates :  
Description
Buildg the jdk on linux-x86 and windows-x64 is failing starting with build 22.

It is failing in javac but looks like it is related to the VM. If a Build 21 libjvm.so is copied in, the failure goes away.

The build failure looks like:

...
# Running javac:
/opt/java/jdk1.7.0/bin/javac -J-XX:ThreadStackSize=1536 -J-Xmx868m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -source 1.5 -target 5 -encoding ascii -Xbootclasspath:../../../build/linux-amd64/classes -sourcepath ../../../src/closed/solaris/classes:../../../src/closed/share/classes:../../../build/linux-amd64/gensrc:../../../src/solaris/classes:../../../src/share/classes -d ../../../build/linux-amd64/classes @../../../build/linux-amd64/tmp/java/java.lang/java/.classes.list
An exception has occurred in the compiler (1.7.0-ea). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport)  after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report.  Thank you.
java.lang.ArrayIndexOutOfBoundsException: -2147483521
        at java.lang.Long.valueOf(Long.java:571)
        at com.sun.tools.javac.jvm.Items$ImmediateItem.coerce(Items.java:622)
        at com.sun.tools.javac.jvm.Items$Item.coerce(Items.java:264)
        at com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:834)
        at com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:851)
        at com.sun.tools.javac.jvm.Gen.visitApply(Gen.java:1678)
        at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1296)
        at com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:832)
        at com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:851)
        at com.sun.tools.javac.jvm.Gen.visitApply(Gen.java:1678)
        at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1296)
        at com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:832)
        at com.sun.tools.javac.jvm.Gen.visitTypeCast(Gen.java:2054)
...
sparc64 build also fails, so it looks like a generic 64-bit problem.

Comments
EVALUATION Unrelated ConvI2L nodes could be merged and their type narrowed incorrectly. In the bug's test case we inline the code: Long.valueOf(Integer.longValue()) There are two original ConvI2L nodes: one for the range check and an other for LongCache.cache[] element reference: public static Long valueOf(long l) { final int offset = 128; if (l >= -128 && l <= 127) { // will cache return LongCache.cache[(int)l + offset]; } return new Long(l); } The size of LongCache.cache[] is 256. The type of the second ConvI2L is [-128, 127] after splitting through AddI '(int)l + offset'. In ConvI2L::Ideal() both ConvI2L nodes are merged with type [-128, 127] since both don't have control edge and have the same input. As result we remove the range check code since it is always true. And when an out of range value is passed we get ArrayIndexOutOfBoundsException.
2007-10-17

SUGGESTED FIX Webrev: http://prt-web.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2007/20071016155946.kvn.6616627/workspace/webrevs/webrev-2007.10.16/index.html Restore the code in ConvI2LNode::Ideal() back before 6602875 changes. This fix will cause performance regression of 64-bits VM comparing to b22 but it still should be better then b21. There is plan to get performance back in future builds by using other optimization.
2007-10-17

EVALUATION Caused by changes in ConvI2LNode::Ideal() method. < 2c8 B38: # B42 B39 &lt;- B37 Freq: 142.164 < 2c8 # checkcastPP of RBP < 2c8 movl RCX, [RBP + #16 (8-bit)] # int ! Field java/lang/Integer.value < 2cb movslq RBX, RCX # i2l < 2ce cmpq RBX, #-128 < 2d2 jlt,s B42 P=0.500000 C=-1.000000 < 2d2 < 2d4 B39: # B42 B40 &lt;- B38 Freq: 71.0819 < 2d4 cmpq RBX, #127 < 2d8 jgt,s B42 P=0.500000 C=-1.000000 < 2d8 < 2da B40: # B120 B41 &lt;- B39 Freq: 35.5409 < 2da addl RCX, #128 # int < 2e0 movq R10, precise klass java/lang/Long$LongCache: 0x0000002adba9f1c8:Constant:exact * # ptr < 2ea movq RBP, [R10 + #568 (32-bit)] # ptr ! Field java/lang/Long$LongCache.cache < 2f1 cmpl RCX, #256 # unsigned < 2f7 jge,u B120 P=0.000001 C=-1.000000 < 2f7 < 2fd B41: # B45 &lt;- B40 Freq: 35.5409 < 2fd movq RBP, [RBP + #1048 + RBX &lt;&lt; #3] # ptr < 305 movq R10, R12 # spill < 308 jmp,s B45 < 308 -------------------------------------------------------------------------- > 2c9 B38: # B115 B39 &lt;- B37 Freq: 142.164 > 2c9 # checkcastPP of RBP > 2c9 movl R11, [RBP + #16 (8-bit)] # int ! Field java/lang/Integer.value > 2cd movl R8, R11 # spill > 2d0 addl R8, #128 # int > 2d7 movq R10, precise klass java/lang/Long$LongCache: 0x0000002adb3962d8:Constant:exact * # ptr > 2e1 movq RBP, [R10 + #568 (32-bit)] # ptr ! Field java/lang/Long$LongCache.cache > 2e8 cmpl R8, #256 # unsigned > 2ef jge,u B115 P=0.000001 C=-1.000000 > 2ef > 2f5 B39: # B114 B40 &lt;- B38 Freq: 142.164 > 2f5 movq [R9 + #40 (8-bit)], R12 # ptr ! Field com/sun/tools/javac/jvm/Items$ImmediateItem.this$0 > 2f9 movq [rsp + #8], R12 # spill > 2fe movq R8, R9 # ptr -&gt; long > 301 movq [rsp + #0], R9 # spill > 305 movslq R11, R11 # i2l > 308 movq RBP, [RBP + #1048 + R11 &lt;&lt; #3] # ptr > 310 shrq R8, #9 > 314 movq R11, 0x0000002ac512f000 # ptr > 31e movb [R11 + R8], #0 # byte > 323 movq RSI, RCX # spill > 326 nop # 1 bytes pad for loops and calls > 327 call,static com.sun.tools.javac.jvm.Code::typecode
2007-10-15