EVALUATION

http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/2ec638646e86
                                     

EVALUATION

See main CR
                                     

EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/2ec638646e86
                                     

EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2ec638646e86
                                     

EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2ec638646e86
                                     

EVALUATION

In SharedRuntime::fixup_callers_callsite there is a bailout on method handle call sites since we cannot fixup these call sites as the executed method handle adapters are doing the required MethodHandle chain work.  fixup_callers_callsite gets passed in a caller_pc which is then passed on to nmethod::is_method_handle_return.  But is_method_handle_return takes a return PC.  On the other architectures these two addresses are the same but on SPARC it's different (frame::pc_return_offset = 2).
                                     

SUGGESTED FIX

Adjust caller_pc by frame::pc_return_offset and pass this value (return_pc) to nmethod::is_method_handle_return.
                                     

EVALUATION

The problem is that in SharedRuntime::fixup_callers_callsite the check for is_method_handle_return on the caller_pc returns false and the call site gets fixed up although it shouldn't:

(dbx) fr 11
0xf9534510:     call     0xf9533f60     ! 0xf9533f60
(dbx) p $pc
$pc = 0xf9534510
(dbx) p CodeCache::find_blob($pc)->as_nmethod_or_null()->print()
Compiled method (c2)   80928   14       4       vm.mlvm.meth.stress.compiler.inlineMHTarget.Test::mh_iplusk (17 bytes)
 total in heap  [0xf9534388,0xf9534858] = 1232
 relocation     [0xf9534458,0xf9534494] = 60
 main code      [0xf95344a0,0xf95345c0] = 288
 stub code      [0xf95345c0,0xf9534628] = 104
 oops           [0xf9534628,0xf9534638] = 16
 scopes data    [0xf9534638,0xf95346bc] = 132
 scopes pcs     [0xf95346bc,0xf953480c] = 336
 dependencies   [0xf953480c,0xf9534810] = 4
 handler table  [0xf9534810,0xf9534858] = 72
CodeCache::find_blob($pc)->as_nmethod_or_null()->print() = (void)
hod_or_null()->is_method_handle_return($pc)                                   <
CodeCache::find_blob($pc)->as_nmethod_or_null()->is_method_handle_return($pc) = 0
                                     

EVALUATION

Using TraceCallFixup shows that the third method handle call site in:

    static int mh_iplusk(MethodHandle a, MethodHandle b, MethodHandle c, int i) throws Throwable {                                                               
        return (int) a.invokeExact(i) + (int) b.invokeExact(i) + (int) c.invokeExact();                                                                          
    }                                                                                                                                                            
gets resolved to a direct call to java.lang.invoke.MethodHandleImpl$FieldAccessor.getFieldI resulting in getFieldI picking up the wrong receiver (the BoundMethodHandle instead of FieldAccessor):

$ java -d32 -XX:+TieredCompilation -XX:+ShowMessageBoxOnError -XX:+TraceCallFixup -cp bin/classes -XX:CompileCommand=compileonly,vm/mlvm/meth*.* -XX:CompileCommand=compileonly,java/lang/invoke*.* -XX:CompileCommand=compileonly,*.getInt vm.mlvm.meth.stress.compiler.inlineMHTarget.Test
VM option '+TieredCompilation'
VM option '-PrintCompilation'
VM option '+ShowMessageBoxOnError'
VM option '+TraceCallFixup'
VM option 'CompileCommand=compileonly,vm/mlvm/meth*.*'
VM option 'CompileCommand=compileonly,java/lang/invoke*.*'
VM option 'CompileCommand=compileonly,*.getInt'
Warning:  Cannot open log file: hotspot.log
Warning:  Forcing option -XX:LogFile=/tmp/hs_pid4173.log
CompilerOracle: compileonly vm/mlvm/meth*.*
CompilerOracle: compileonly java/lang/invoke*.*
CompilerOracle: compileonly *.getInt
resolving optimized virtual (invokevirtual) call to java.lang.Object::getClass code: 0x00000000
resolving optimized virtual (invokevirtual) call to java.lang.invoke.MethodHandle::invokeExact code: 0x00000000
resolving optimized virtual (invokevirtual) call to java.lang.invoke.MethodHandle::invokeExact code: 0x00000000
resolving optimized virtual (invokevirtual) call to java.lang.invoke.MethodHandle::invokeExact code: 0x00000000
resolving optimized virtual (invokevirtual) call to java.lang.invoke.MethodHandle::invokeExact code: 0x00000000
resolving optimized virtual (invokevirtual) call to java.lang.invoke.MethodHandle::invokeExact code: 0x00000000
resolving optimized virtual (invokevirtual) call to java.lang.invoke.MethodHandle::invokeExact code: 0x00000000
resolving optimized virtual (invokevirtual) call to java.lang.invoke.MethodHandle::invokeExact code: 0x00000000
resolving optimized virtual (invokevirtual) call to java.lang.invoke.MethodHandle::invokeExact code: 0x00000000
fixup callsite           at 0xf9534510 to compiled code for java.lang.invoke.MethodHandleImpl$FieldAccessor::getFieldI to 0xf9533f60
==============================================================================
Unexpected Error
------------------------------------------------------------------------------
SIGSEGV (0xb) at pc=0xf9533f80, pid=4173, tid=2

Do you want to debug the problem?

To debug, run 'dbx - 4173'; then switch to thread 2
Enter 'yes' to launch dbx automatically (PATH must include dbx)
Otherwise, press RETURN to abort...
==============================================================================