United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7101642 JSR 292: SIGSEGV in java.lang.invoke.MethodHandleImpl$FieldAccessor.getFieldI(Ljava/lang/Object;)I
JDK-7101642 : JSR 292: SIGSEGV in java.lang.invoke.MethodHandleImpl$FieldAccessor.getFieldI(Ljava/lang/Object;)I

Details
Type:
Bug
Submit Date:
2011-10-17
Status:
Closed
Updated Date:
2012-03-22
Project Name:
JDK
Resolved Date:
2012-01-23
Component:
hotspot
OS:
generic
Sub-Component:
compiler
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs22
Fixed Versions:
hs23 (b06)

Related Reports
Backport:
Backport:

Sub Tasks

Description
VM crashes with -XX:+TieredCompilation on solaris-sparc:

# SIGSEGV (0xb) at pc=0xfa0a3c80, pid=20849, tid=2                                    

# JRE version: 8.0-b05
# Java VM: Java HotSpot(TM) Server VM (22.0-b03 mixed mode solaris-sparc )               

Stack: [0xfe200000,0xfe280000],  sp=0xfe27f818,  free space=510k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
J  java.lang.invoke.MethodHandleImpl$FieldAccessor.getFieldI(Ljava/lang/Object;)I

                                    

Comments
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
                                     
2011-10-21
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...
==============================================================================
                                     
2011-10-21
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).
                                     
2011-10-24
SUGGESTED FIX

Adjust caller_pc by frame::pc_return_offset and pass this value (return_pc) to nmethod::is_method_handle_return.
                                     
2011-10-24
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2ec638646e86
                                     
2011-10-25
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/2ec638646e86
                                     
2011-11-15
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot/rev/2ec638646e86
                                     
2011-11-29
EVALUATION

See main CR
                                     
2011-11-30
EVALUATION

http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/2ec638646e86
                                     
2012-03-22



Hardware and Software, Engineered to Work Together