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

MethodHandle inlining with long/double arguments is broken in C2

    Details

    • Subcomponent:
    • Resolved In Build:
      b107

      Backports

        Description

        After the integration of Indify String Concatenation (JDK-8148483), compiler/jvmci/compilerToVM/GetNextStackFrameTest.java fails with the following stack trace:

        java.lang.StringIndexOutOfBoundsException: offset 87, count -1323521248, length 340
        at java.lang.String.checkBoundsOffCount(String.java:3107)
        at java.lang.StringLatin1.inflate(StringLatin1.java:528)
        at java.lang.String.getBytes(String.java:3002)
        at java.lang.AbstractStringBuilder.putStringAt(AbstractStringBuilder.java:1644)
        at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:488)
        at java.lang.StringBuilder.append(StringBuilder.java:141)
        at java.lang.StringBuilder.append(StringBuilder.java:135)
        at java.lang.String$Concat/55860507.concat(Unknown Source)
        at jdk.vm.ci.hotspot.HotSpotStackFrameReference.toString(HotSpotStackFrameReference.java:90)
        at jdk.test.lib.Asserts.format(Asserts.java:443)

        It also fails with -XX:-OptimizeStringConcat:

        java.lang.ArrayStoreException
        at java.lang.System.arraycopy(Native Method)
        at java.lang.String.getBytes(String.java:3000)
        at java.lang.AbstractStringBuilder.putStringAt(AbstractStringBuilder.java:1644)
        at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:488)
        at java.lang.StringBuilder.append(StringBuilder.java:141)
        at java.lang.StringBuilder.append(StringBuilder.java:135)
        at java.lang.String$Concat/931594624.concat(Unknown Source)
        at jdk.vm.ci.hotspot.HotSpotStackFrameReference.toString(HotSpotStackFrameReference.java:90)
        at jdk.test.lib.Asserts.format(Asserts.java:443)

        It does not fail with -Djava.lang.invoke.stringConcat=MH_SB_SIZED.

          Issue Links

            Activity

            Hide
            shade Aleksey Shipilev added a comment - - edited
            Removing @ForceInline from the generated method in BC_* strategies seems to avoid the issue. A clue?

            diff -r f90110e9109d src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
            --- a/src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java Wed Feb 03 00:49:41 2016 +0300
            +++ b/src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java Wed Feb 03 01:14:47 2016 +0300
            @@ -757,7 +757,7 @@
                                 null,
                                 null);
             
            - mv.visitAnnotation("Ljdk/internal/vm/annotation/ForceInline;", true);
            +// mv.visitAnnotation("Ljdk/internal/vm/annotation/ForceInline;", true);
                         mv.visitCode();
             
                         Class<?>[] arr = args.parameterArray();
            Show
            shade Aleksey Shipilev added a comment - - edited Removing @ForceInline from the generated method in BC_* strategies seems to avoid the issue. A clue? diff -r f90110e9109d src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java --- a/src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java Wed Feb 03 00:49:41 2016 +0300 +++ b/src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java Wed Feb 03 01:14:47 2016 +0300 @@ -757,7 +757,7 @@                      null,                      null);   - mv.visitAnnotation("Ljdk/internal/vm/annotation/ForceInline;", true); +// mv.visitAnnotation("Ljdk/internal/vm/annotation/ForceInline;", true);              mv.visitCode();                Class<?>[] arr = args.parameterArray();
            Hide
            thartmann Tobias Hartmann added a comment -
            Here is the relevant stack:
            V [libjvm.so+0x9fc696] Exceptions::_throw_msg(Thread*, char const*, int, Symbol*, char const*)+0x146
            V [libjvm.so+0xca5553] JVM_ArrayCopy+0x2f3
            J 1035 java.lang.System.arraycopy(Ljava/lang/Object;ILjava/lang/Object;II)V (0 bytes) @ 0x00007f1fe5388711 [0x00007f1fe53885a0+0x0000000000000171]
            j java.lang.String.getBytes([BIB)V+22
            J 59 C2 java.lang.AbstractStringBuilder.append(Ljava/lang/String;)Ljava/lang/AbstractStringBuilder; (129 bytes) @ 0x00007f1fe51c1804 [0x00007f1fe51c16c0+0x0000000000000144]
            J 3299 C2 jdk.vm.ci.hotspot.HotSpotStackFrameReference.toString()Ljava/lang/String; (36 bytes) @ 0x00007f1fe580eea0 [0x00007f1fe580eae0+0x00000000000003c0]
            J 3298 C2 compiler.jvmci.compilerToVM.GetNextStackFrameTest.walkThrough()V (120 bytes) @ 0x00007f1fe581e760 [0x00007f1fe581e4c0+0x00000000000002a0]

            The problem is in the C2 compiled method HotSpotStackFrameReference.toString():
              0x00007f767cc7121b: mov 0x20(%rsi),%r11d
              ...
              0x00007f767cc712aa: shl $0x3,%r11 ;*getfield method {reexecute=0 rethrow=0 return_oop=0}
              ...
              0x00007f767cc71445: mov %r11,0x30(%rsp)
              ...
              0x00007f767cc715f4: mov 0x30(%rsp),%rdx
              0x00007f767cc715f9: test %rdx,%rdx
              0x00007f767cc715fc: je 0x00007f767cc71710
              0x00007f767cc71602: mov %rbp,%rsi
              0x00007f767cc71605: nop
              0x00007f767cc71606: nop
              0x00007f767cc71607: callq 0x00007f767c47d280 ; call java.lang.StringBuilder::append(String)

            We call StringBuilder.append(String) with the String argument in $rdx but the actual argument is not a String but a HotSpotResolvedJavaMethodImpl:
            (rr) print/x $rdx
            $3 = 0x6cab6f928
            (rr) call pp(0x6cab6f928)
            "Executing pp"
            jdk.vm.ci.hotspot.HotSpotResolvedJavaMethodImpl
             - klass: 'jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl'
             - ---- fields (total size 6 words):
             - protected 'name' 'Ljava/lang/String;' @12 "frame4" (d956df2b e3f357a8)
             - private final 'metaspaceMethod' 'J' @16 139774945089448 (e3f357a8 7f1f)
             - private final 'holder' 'Ljdk/vm/ci/hotspot/HotSpotResolvedObjectTypeImpl;' @24 a 'jdk/vm/ci/hotspot/HotSpotResolvedObjectTypeImpl' (d956d188 d956dc93)
             - private final 'constantPool' 'Ljdk/vm/ci/hotspot/HotSpotConstantPool;' @28 a 'jdk/vm/ci/hotspot/HotSpotConstantPool' (d956dc93 d956df32)
             - private final 'signature' 'Ljdk/vm/ci/hotspot/HotSpotSignature;' @32 a 'jdk/vm/ci/hotspot/HotSpotSignature' (d956df32 0)
             - private 'methodData' 'Ljdk/vm/ci/hotspot/HotSpotMethodData;' @36 NULL (0 0)
             - private 'code' '[B' @40 NULL (0 0)
             - private 'toJavaCache' 'Ljava/lang/reflect/Executable;' @44 NULL (0 5)

            The bytecode is correct and calls StringBuilder.append(Object) to append the method object:
                  34: ldc #31 // String , method=
                  36: invokevirtual #19 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
                  39: aload 4
                  41: invokevirtual #34 // Method java/lang/StringBuilder.append:(Ljava/lang/Object;)Ljava/lang/StringBuilder;

            It seems that C2 assumes that the argument object is always a String and therefore inlines String.toString():
                                                @ 41 java.lang.StringBuilder::append (9 bytes) inline (hot)
                                                  @ 2 java.lang.String::valueOf (14 bytes) inline (hot)
                                                    @ 10 java.lang.String::toString (2 bytes) inline (hot)

            We fail later in arraycopy after accessing String.value from an object which is not a String.
            Show
            thartmann Tobias Hartmann added a comment - Here is the relevant stack: V [libjvm.so+0x9fc696] Exceptions::_throw_msg(Thread*, char const*, int, Symbol*, char const*)+0x146 V [libjvm.so+0xca5553] JVM_ArrayCopy+0x2f3 J 1035 java.lang.System.arraycopy(Ljava/lang/Object;ILjava/lang/Object;II)V (0 bytes) @ 0x00007f1fe5388711 [0x00007f1fe53885a0+0x0000000000000171] j java.lang.String.getBytes([BIB)V+22 J 59 C2 java.lang.AbstractStringBuilder.append(Ljava/lang/String;)Ljava/lang/AbstractStringBuilder; (129 bytes) @ 0x00007f1fe51c1804 [0x00007f1fe51c16c0+0x0000000000000144] J 3299 C2 jdk.vm.ci.hotspot.HotSpotStackFrameReference.toString()Ljava/lang/String; (36 bytes) @ 0x00007f1fe580eea0 [0x00007f1fe580eae0+0x00000000000003c0] J 3298 C2 compiler.jvmci.compilerToVM.GetNextStackFrameTest.walkThrough()V (120 bytes) @ 0x00007f1fe581e760 [0x00007f1fe581e4c0+0x00000000000002a0] The problem is in the C2 compiled method HotSpotStackFrameReference.toString():   0x00007f767cc7121b: mov 0x20(%rsi),%r11d   ...   0x00007f767cc712aa: shl $0x3,%r11 ;*getfield method {reexecute=0 rethrow=0 return_oop=0}   ...   0x00007f767cc71445: mov %r11,0x30(%rsp)   ...   0x00007f767cc715f4: mov 0x30(%rsp),%rdx   0x00007f767cc715f9: test %rdx,%rdx   0x00007f767cc715fc: je 0x00007f767cc71710   0x00007f767cc71602: mov %rbp,%rsi   0x00007f767cc71605: nop   0x00007f767cc71606: nop   0x00007f767cc71607: callq 0x00007f767c47d280 ; call java.lang.StringBuilder::append(String) We call StringBuilder.append(String) with the String argument in $rdx but the actual argument is not a String but a HotSpotResolvedJavaMethodImpl: (rr) print/x $rdx $3 = 0x6cab6f928 (rr) call pp(0x6cab6f928) "Executing pp" jdk.vm.ci.hotspot.HotSpotResolvedJavaMethodImpl  - klass: 'jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl'  - ---- fields (total size 6 words):  - protected 'name' 'Ljava/lang/String;' @12 "frame4" (d956df2b e3f357a8)  - private final 'metaspaceMethod' 'J' @16 139774945089448 (e3f357a8 7f1f)  - private final 'holder' 'Ljdk/vm/ci/hotspot/HotSpotResolvedObjectTypeImpl;' @24 a 'jdk/vm/ci/hotspot/HotSpotResolvedObjectTypeImpl' (d956d188 d956dc93)  - private final 'constantPool' 'Ljdk/vm/ci/hotspot/HotSpotConstantPool;' @28 a 'jdk/vm/ci/hotspot/HotSpotConstantPool' (d956dc93 d956df32)  - private final 'signature' 'Ljdk/vm/ci/hotspot/HotSpotSignature;' @32 a 'jdk/vm/ci/hotspot/HotSpotSignature' (d956df32 0)  - private 'methodData' 'Ljdk/vm/ci/hotspot/HotSpotMethodData;' @36 NULL (0 0)  - private 'code' '[B' @40 NULL (0 0)  - private 'toJavaCache' 'Ljava/lang/reflect/Executable;' @44 NULL (0 5) The bytecode is correct and calls StringBuilder.append(Object) to append the method object:       34: ldc #31 // String , method=       36: invokevirtual #19 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;       39: aload 4       41: invokevirtual #34 // Method java/lang/StringBuilder.append:(Ljava/lang/Object;)Ljava/lang/StringBuilder; It seems that C2 assumes that the argument object is always a String and therefore inlines String.toString():                                     @ 41 java.lang.StringBuilder::append (9 bytes) inline (hot)                                       @ 2 java.lang.String::valueOf (14 bytes) inline (hot)                                         @ 10 java.lang.String::toString (2 bytes) inline (hot) We fail later in arraycopy after accessing String.value from an object which is not a String.
            Hide
            thartmann Tobias Hartmann added a comment -
            HotSpotStackFrameReference::toString() looks like this:

            1 fast_lgetfield 2 <jdk/vm/ci/hotspot/HotSpotStackFrameReference.stackPointer/J>
            4 aload_0
            5 fast_igetfield 3 <jdk/vm/ci/hotspot/HotSpotStackFrameReference.frameNumber/I>
            8 aload_0
            9 fast_igetfield 8 <jdk/vm/ci/hotspot/HotSpotStackFrameReference.bci/I>
            12 fast_aload_0
            13 invokevirtual 11 <jdk/vm/ci/hotspot/HotSpotStackFrameReference.getMethod()Ljdk/vm/ci/meta/ResolvedJavaMethod;>
              0 bci: 13 VirtualCallData count(0) nonprofiled_count(0) entries(1)
                                                'jdk/vm/ci/hotspot/HotSpotStackFrameReference'(1 1.00)
                                                method_entries(0)
            16 aload_0
            17 fast_agetfield 4 <jdk/vm/ci/hotspot/HotSpotStackFrameReference.locals/[Ljava/lang/Object;>
            20 invokestatic 12 <java/util/Arrays.toString([Ljava/lang/Object;)Ljava/lang/String;>
              56 bci: 20 CounterData count(1)
            23 aload_0
            24 fast_agetfield 5 <jdk/vm/ci/hotspot/HotSpotStackFrameReference.localIsVirtual/[Z>
            27 invokestatic 13 <java/util/Arrays.toString([Z)Ljava/lang/String;>
              72 bci: 27 CounterData count(1)
            30 invokedynamic bsm=81 14 <makeConcatWithConstants(JIILjdk/vm/ci/meta/ResolvedJavaMethod;Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;>
              88 bci: 30 CounterData count(2)
            35 areturn

            The invokedynamic @ bci:30 is resolved and inlined like this:

            345117010::invokeStatic_JIIL3_L @ bci:21
            1163020763::reinvoke @ bci:24
            62297476::linkToTargetMethod @ bci:14
            HotSpotStackFrameReference::toString @ bci:30

            In CallGenerator::for_method_handle_inline() we inline invokeStatic_JIIL3_L and cast the reference arguments to its type. The graph looks similar to this:

             62 CreateEx === 59 52 [[ 61 ]] #java/lang/Throwable:NotNull * Oop:java/lang/Throwable:NotNull * !jvms: HotSpotStackFrameReference::toString @ bci:20
             49 DecodeN === _ 48 [[ 61 50 ]] #narrowoop: java/lang/Object *[int:>=0] * !jvms: HotSpotStackFrameReference::toString @ bci:17
             45 DecodeN === _ 44 [[ 38 33 50 61 ]] #jdk/vm/ci/hotspot/HotSpotResolvedJavaMethod * Interface:jdk/vm/ci/hotspot/HotSpotResolvedJavaMethod * !jvms: HotSpotStackFrameReference::getMethod @ bci:1 HotSpotStackFrameReference::toString @ bci:13
             31 LoadI === _ 7 30 [[ 21 33 50 61 ]] @jdk/vm/ci/hotspot/HotSpotStackFrameReference+24 *, name=bci, idx=6; #int !jvms: HotSpotStackFrameReference::toString @ bci:9
             28 LoadI === _ 7 27 [[ 21 33 50 61 ]] @jdk/vm/ci/hotspot/HotSpotStackFrameReference+12 *, name=frameNumber, idx=5; #int !jvms: HotSpotStackFrameReference::toString @ bci:5
             25 LoadL === _ 7 24 [[ 21 33 50 61 ]] @jdk/vm/ci/hotspot/HotSpotStackFrameReference+16 *, name=stackPointer, idx=4; #long !jvms: HotSpotStackFrameReference::toString @ bci:1
             10 Parm === 3 [[ 4 18 21 24 24 27 27 30 30 21 33 39 43 43 47 47 50 61 ]] Parm0: jdk/vm/ci/hotspot/HotSpotStackFrameReference:NotNull * Oop:jdk/vm/ci/hotspot/HotSpotStackFrameReference:NotNull * !jvms: HotSpotStackFrameReference::toString @ bci:-1
             9 Parm === 3 [[ 4 12 18 21 33 39 61 ]] ReturnAdr !jvms: HotSpotStackFrameReference::toString @ bci:-1
             8 Parm === 3 [[ 4 12 18 21 33 39 50 61 ]] FramePtr !jvms: HotSpotStackFrameReference::toString @ bci:-1
             60 MergeMem === _ 1 53 1 [[ 61 ]] { - } Memory: @BotPTR *+bot, idx=Bot; !jvms: HotSpotStackFrameReference::toString @ bci:20
             52 Proj === 50 [[ 33 57 61 62 ]] #1 !jvms: HotSpotStackFrameReference::toString @ bci:20
             59 CatchProj === 57 [[ 61 62 ]] #1@bci -1 !jvms: HotSpotStackFrameReference::toString @ bci:20
             61 SafePoint === 59 52 60 8 9 10 25 1 28 31 45 49 1 1 62 [[]] SafePoint !orig=33,21,18

            The JIIL3 arguments are (25 1), 28, 31, ... The problem is that in CallGenerator::for_method_handle_inline() we handle the long tuple (25 1) as two arguments and therefore cast the 3rd argument (45 DecodeN) from Object to String (because the 4th argument is of type String):

             43 AddP === _ 10 10 42 [[ 44 ]] Oop:jdk/vm/ci/hotspot/HotSpotStackFrameReference:NotNull+32 * [narrow] !jvms: HotSpotStackFrameReference::getMethod @ bci:1 HotSpotStackFrameReference::toString @ bci:13
             7 Parm === 3 [[ 4 11 19 20 25 28 31 32 40 44 36 37 48 50 63 82 ]] Memory Memory: @BotPTR *+bot, idx=Bot; !jvms: HotSpotStackFrameReference::toString @ bci:-1
             71 Proj === 69 [[ 33 76 80 81 83 85 96 98 107 109 119 121 129 125 123 ]] #1 !jvms: HotSpotStackFrameReference::toString @ bci:27
             70 Proj === 69 [[ 76 ]] #0 !jvms: HotSpotStackFrameReference::toString @ bci:27
             44 LoadN === _ 7 43 [[ 45 ]] @jdk/vm/ci/hotspot/HotSpotStackFrameReference+32 * [narrow], name=method, idx=7; #narrowoop: jdk/vm/ci/hotspot/HotSpotResolvedJavaMethod * !jvms: HotSpotStackFrameReference::getMethod @ bci:1 HotSpotStackFrameReference::toString @ bci:13
             76 Catch === 70 71 [[ 77 78 ]] !jvms: HotSpotStackFrameReference::toString @ bci:27
             45 DecodeN === _ 44 [[ 38 33 50 61 69 80 96 98 107 109 119 121 123 135 ]] #jdk/vm/ci/hotspot/HotSpotResolvedJavaMethod * Interface:jdk/vm/ci/hotspot/HotSpotResolvedJavaMethod * !jvms: HotSpotStackFrameReference::getMethod @ bci:1 HotSpotStackFrameReference::toString @ bci:13
             77 CatchProj === 76 [[ 33 96 98 107 109 119 121 129 124 135 ]] #0@bci -1 !jvms: HotSpotStackFrameReference::toString @ bci:27
             135 CheckCastPP === 77 45 [[]] #java/lang/String:exact * Oop:java/lang/String:exact * !jvms: 345117010::invokeStatic_JIIL3_L @ bci:21 1163020763::reinvoke @ bci:24 62297476::linkToTargetMethod @ bci:14 HotSpotStackFrameReference::toString @ bci:30

            As a result, C2 assumes the 3rd argument is always of type String and inlines String.toString(). However, at runtime the type is 'ResolvedJavaMethod', causing the crash.
            Show
            thartmann Tobias Hartmann added a comment - HotSpotStackFrameReference::toString() looks like this: 1 fast_lgetfield 2 <jdk/vm/ci/hotspot/HotSpotStackFrameReference.stackPointer/J> 4 aload_0 5 fast_igetfield 3 <jdk/vm/ci/hotspot/HotSpotStackFrameReference.frameNumber/I> 8 aload_0 9 fast_igetfield 8 <jdk/vm/ci/hotspot/HotSpotStackFrameReference.bci/I> 12 fast_aload_0 13 invokevirtual 11 <jdk/vm/ci/hotspot/HotSpotStackFrameReference.getMethod()Ljdk/vm/ci/meta/ResolvedJavaMethod;>   0 bci: 13 VirtualCallData count(0) nonprofiled_count(0) entries(1)                                     'jdk/vm/ci/hotspot/HotSpotStackFrameReference'(1 1.00)                                     method_entries(0) 16 aload_0 17 fast_agetfield 4 <jdk/vm/ci/hotspot/HotSpotStackFrameReference.locals/[Ljava/lang/Object;> 20 invokestatic 12 <java/util/Arrays.toString([Ljava/lang/Object;)Ljava/lang/String;>   56 bci: 20 CounterData count(1) 23 aload_0 24 fast_agetfield 5 <jdk/vm/ci/hotspot/HotSpotStackFrameReference.localIsVirtual/[Z> 27 invokestatic 13 <java/util/Arrays.toString([Z)Ljava/lang/String;>   72 bci: 27 CounterData count(1) 30 invokedynamic bsm=81 14 <makeConcatWithConstants(JIILjdk/vm/ci/meta/ResolvedJavaMethod;Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;>   88 bci: 30 CounterData count(2) 35 areturn The invokedynamic @ bci:30 is resolved and inlined like this: 345117010::invokeStatic_JIIL3_L @ bci:21 1163020763::reinvoke @ bci:24 62297476::linkToTargetMethod @ bci:14 HotSpotStackFrameReference::toString @ bci:30 In CallGenerator::for_method_handle_inline() we inline invokeStatic_JIIL3_L and cast the reference arguments to its type. The graph looks similar to this:  62 CreateEx === 59 52 [[ 61 ]] #java/lang/Throwable:NotNull * Oop:java/lang/Throwable:NotNull * !jvms: HotSpotStackFrameReference::toString @ bci:20  49 DecodeN === _ 48 [[ 61 50 ]] #narrowoop: java/lang/Object *[int:>=0] * !jvms: HotSpotStackFrameReference::toString @ bci:17  45 DecodeN === _ 44 [[ 38 33 50 61 ]] #jdk/vm/ci/hotspot/HotSpotResolvedJavaMethod * Interface:jdk/vm/ci/hotspot/HotSpotResolvedJavaMethod * !jvms: HotSpotStackFrameReference::getMethod @ bci:1 HotSpotStackFrameReference::toString @ bci:13  31 LoadI === _ 7 30 [[ 21 33 50 61 ]] @jdk/vm/ci/hotspot/HotSpotStackFrameReference+24 *, name=bci, idx=6; #int !jvms: HotSpotStackFrameReference::toString @ bci:9  28 LoadI === _ 7 27 [[ 21 33 50 61 ]] @jdk/vm/ci/hotspot/HotSpotStackFrameReference+12 *, name=frameNumber, idx=5; #int !jvms: HotSpotStackFrameReference::toString @ bci:5  25 LoadL === _ 7 24 [[ 21 33 50 61 ]] @jdk/vm/ci/hotspot/HotSpotStackFrameReference+16 *, name=stackPointer, idx=4; #long !jvms: HotSpotStackFrameReference::toString @ bci:1  10 Parm === 3 [[ 4 18 21 24 24 27 27 30 30 21 33 39 43 43 47 47 50 61 ]] Parm0: jdk/vm/ci/hotspot/HotSpotStackFrameReference:NotNull * Oop:jdk/vm/ci/hotspot/HotSpotStackFrameReference:NotNull * !jvms: HotSpotStackFrameReference::toString @ bci:-1  9 Parm === 3 [[ 4 12 18 21 33 39 61 ]] ReturnAdr !jvms: HotSpotStackFrameReference::toString @ bci:-1  8 Parm === 3 [[ 4 12 18 21 33 39 50 61 ]] FramePtr !jvms: HotSpotStackFrameReference::toString @ bci:-1  60 MergeMem === _ 1 53 1 [[ 61 ]] { - } Memory: @BotPTR *+bot, idx=Bot; !jvms: HotSpotStackFrameReference::toString @ bci:20  52 Proj === 50 [[ 33 57 61 62 ]] #1 !jvms: HotSpotStackFrameReference::toString @ bci:20  59 CatchProj === 57 [[ 61 62 ]] # 1@bci -1 !jvms: HotSpotStackFrameReference::toString @ bci:20  61 SafePoint === 59 52 60 8 9 10 25 1 28 31 45 49 1 1 62 [[]] SafePoint !orig=33,21,18 The JIIL3 arguments are (25 1), 28, 31, ... The problem is that in CallGenerator::for_method_handle_inline() we handle the long tuple (25 1) as two arguments and therefore cast the 3rd argument (45 DecodeN) from Object to String (because the 4th argument is of type String):  43 AddP === _ 10 10 42 [[ 44 ]] Oop:jdk/vm/ci/hotspot/HotSpotStackFrameReference:NotNull+32 * [narrow] !jvms: HotSpotStackFrameReference::getMethod @ bci:1 HotSpotStackFrameReference::toString @ bci:13  7 Parm === 3 [[ 4 11 19 20 25 28 31 32 40 44 36 37 48 50 63 82 ]] Memory Memory: @BotPTR *+bot, idx=Bot; !jvms: HotSpotStackFrameReference::toString @ bci:-1  71 Proj === 69 [[ 33 76 80 81 83 85 96 98 107 109 119 121 129 125 123 ]] #1 !jvms: HotSpotStackFrameReference::toString @ bci:27  70 Proj === 69 [[ 76 ]] #0 !jvms: HotSpotStackFrameReference::toString @ bci:27  44 LoadN === _ 7 43 [[ 45 ]] @jdk/vm/ci/hotspot/HotSpotStackFrameReference+32 * [narrow], name=method, idx=7; #narrowoop: jdk/vm/ci/hotspot/HotSpotResolvedJavaMethod * !jvms: HotSpotStackFrameReference::getMethod @ bci:1 HotSpotStackFrameReference::toString @ bci:13  76 Catch === 70 71 [[ 77 78 ]] !jvms: HotSpotStackFrameReference::toString @ bci:27  45 DecodeN === _ 44 [[ 38 33 50 61 69 80 96 98 107 109 119 121 123 135 ]] #jdk/vm/ci/hotspot/HotSpotResolvedJavaMethod * Interface:jdk/vm/ci/hotspot/HotSpotResolvedJavaMethod * !jvms: HotSpotStackFrameReference::getMethod @ bci:1 HotSpotStackFrameReference::toString @ bci:13  77 CatchProj === 76 [[ 33 96 98 107 109 119 121 129 124 135 ]] # 0@bci -1 !jvms: HotSpotStackFrameReference::toString @ bci:27  135 CheckCastPP === 77 45 [[]] #java/lang/String:exact * Oop:java/lang/String:exact * !jvms: 345117010::invokeStatic_JIIL3_L @ bci:21 1163020763::reinvoke @ bci:24 62297476::linkToTargetMethod @ bci:14 HotSpotStackFrameReference::toString @ bci:30 As a result, C2 assumes the 3rd argument is always of type String and inlines String.toString(). However, at runtime the type is 'ResolvedJavaMethod', causing the crash.
            Hide
            thartmann Tobias Hartmann added a comment -
            We should handle this like C1 does in GraphBuilder::try_method_handle_inline():
            http://cr.openjdk.java.net/~thartmann/8148752/webrev.00/
            Show
            thartmann Tobias Hartmann added a comment - We should handle this like C1 does in GraphBuilder::try_method_handle_inline(): http://cr.openjdk.java.net/~thartmann/8148752/webrev.00/
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4130663a3de8
            User: thartmann
            Date: 2016-02-10 08:03:48 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4130663a3de8 User: thartmann Date: 2016-02-10 08:03:48 +0000
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4130663a3de8
            User: lana
            Date: 2016-02-24 20:06:28 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4130663a3de8 User: lana Date: 2016-02-24 20:06:28 +0000
            Hide
            thartmann Tobias Hartmann added a comment -
            Changed title from "Compiled StringBuilder code throws StringIndexOutOfBoundsException" to "MethodHandle inlining with long/double arguments is broken in C2" because this bug is likely to show up in other variants.
            Show
            thartmann Tobias Hartmann added a comment - Changed title from "Compiled StringBuilder code throws StringIndexOutOfBoundsException" to "MethodHandle inlining with long/double arguments is broken in C2" because this bug is likely to show up in other variants.

              People

              • Assignee:
                thartmann Tobias Hartmann
                Reporter:
                thartmann Tobias Hartmann
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: