United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6616627 64-bit j2se build problem: ArrayIndexOutOfBoundsException: -2147483521
JDK-6616627 : 64-bit j2se build problem: ArrayIndexOutOfBoundsException: -2147483521

Details
Type:
Bug
Submit Date:
2007-10-14
Status:
Closed
Updated Date:
2011-04-23
Project Name:
JDK
Resolved Date:
2011-04-23
Component:
hotspot
OS:
generic
Sub-Component:
compiler
CPU:
generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
7
Fixed Versions:
hs12 (b02)

Related Reports
Backport:
Backport:
Backport:
Backport:
Relates:

Sub Tasks

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

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
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

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



Hardware and Software, Engineered to Work Together