JDK-6986944 : JSR 292 assert(caller_nm->is_method_handle_return(caller_frame.pc())) failed: must be MH call site
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs20,7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2010-09-23
  • Updated: 2011-04-20
  • Resolved: 2011-03-08
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 Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u25Fixed 7Fixed hs20Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
http://sqeweb.sfbay.sun.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2010-08-11/Comp_Baseline/javase/solaris-i586/client/comp/solaris-i586_javase_client_comp_JT_JDK_java_dyn/workDir/java/dyn/MethodHandlesTest/hs_err_pid9097.log

#  Internal Error (/tmp/jprt/P1/B/175109.kvn/source/src/share/vm/runtime/sharedRuntime.cpp:1057), pid=9097, tid=12
#  assert(caller_nm->is_method_handle_return(caller_frame.pc())) failed: must be MH call site
#
# JRE version: 7.0
# Java VM: OpenJDK Client VM (19.0-b04-201008111751.kvn.6973329-fastdebug compiled mode, sharing solaris-x86 )

V  [libjvm.so+0x7c1d39];;  __1cPreport_vm_error6Fpkci11_v_+0x5ad
V  [libjvm.so+0x13ee061];;  __1cNSharedRuntimeSresolve_sub_helper6FpnKJavaThread_bbpnGThread__nMmethodHandle__+0x1a25
V  [libjvm.so+0x13ec1ee];;  __1cNSharedRuntimeOresolve_helper6FpnKJavaThread_bbpnGThread__nMmethodHandle__+0x3a
V  [libjvm.so+0x13f00a8];;  __1cNSharedRuntimeWresolve_virtual_call_C6FpnKJavaThread__pC_+0x110
v  ~RuntimeStub::resolve_virtual_call
J  java.dyn.MethodHandle.invokeVarargs([Ljava/lang/Object;)Ljava/lang/Object;
V  [libjvm.so+0xa666fa];;  __1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x78a
V  [libjvm.so+0x12a8837];;  __1cCosUos_exception_wrapper6FpFpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v2468_v_+0x17
V  [libjvm.so+0xa65f3c];;  __1cJJavaCallsEcall6FpnJJavaValue_nMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x44

Comments
PUBLIC COMMENTS This bug has come back with 7012648. It seems we missed at least one case where all this name mangling does not work: this one. But it should be fixed again with 6981791 which removes all the transitional code.
21-03-2011

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c93c652551b5
09-10-2010

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c93c652551b5
24-09-2010

EVALUATION This one happens because of that change: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/diff/e0ba4e04c839/src/share/vm/ci/ciMethod.cpp as part of: 6969574: invokedynamic call sites deoptimize instead of executing The problem is that C1 calls ciMethod::is_method_handle_invoke in LIRGenerator::do_Invoke. When the target is not loaded yet but is a MH call site, the method returns false and it's not registered as a MH invoke.
23-09-2010

SUGGESTED FIX Restoring the old logic, but only on the non-loaded path: - if (!is_loaded()) return false; + if (!is_loaded()) { + bool flag = (holder()->name() == ciSymbol::java_dyn_MethodHandle() && + methodOopDesc::is_method_handle_invoke_name(name()->sid())); + return flag; + }
23-09-2010