JDK-8034935 : JSR 292 support for PopFrame has a fragile coupling with DirectMethodHandle
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 8
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-02-14
  • Updated: 2015-01-21
  • Resolved: 2014-05-29
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 8 JDK 9
8u40Fixed 9 b17Fixed
Related Reports
Relates :  
JDK-7187554 - JSR 292: JVMTI PopFrame needs to handle appendix arguments
Description
There is a coupling from bytecodes that call MethodHandle.linkToStatic (and similar "linker methods") and the PopFrame feature.  The linker methods accept an extra "appendix argument" of type MemberName which is popped from the list before vectoring to the desired method (it supplies the name of that method). 

In order to re-execute the call, the MemberName must be recovered somehow.  Currently, the JVM assumes that the interpreter frame's local #0 will contain a DirectMethodHandle which holds the desired MemberName.  The JVM should also accept the MemberName itself, and eventually stop looking for the DirectMethodHandle.

This will simplify the handshake between JVM and JSR 292 implementation bytecodes.  The DMH is difficult to recover at the point of call to linkToStatic, although the MemberName is guaranteed live at that point.

Also, making this change (perhaps in two steps) will allow the JVM to stop coupling to SystemDictionary::DirectMethodHandle_klass.  Such couplings should be minimized.
Comments
Suggested fix: diff --git a/src/share/vm/interpreter/interpreterRuntime.cpp b/src/share/vm/interpreter/interpreterRuntime.cpp --- a/src/share/vm/interpreter/interpreterRuntime.cpp +++ b/src/share/vm/interpreter/interpreterRuntime.cpp @@ -1240,7 +1240,8 @@ // This is a support of the JVMTI PopFrame interface. // Make sure it is an invokestatic of a polymorphic intrinsic that has a member_name argument // and return it as a vm_result so that it can be reloaded in the list of invokestatic parameters. -// The dmh argument is a reference to a DirectMethoHandle that has a member name field. +// The dmh argument is a saved reference (in local#0) to the member_name. +// For backward compatibility with some JDK versions (7, 8) it can also be a direct method handle. IRT_ENTRY(void, InterpreterRuntime::member_name_arg_or_null(JavaThread* thread, address dmh, Method* method, address bcp)) Bytecodes::Code code = Bytecodes::code_at(method, bcp); @@ -1253,7 +1254,15 @@ Symbol* mname = cpool->name_ref_at(cp_index); if (MethodHandles::has_member_arg(cname, mname)) { - oop member_name = java_lang_invoke_DirectMethodHandle::member((oop)dmh); + oop member_name = NULL; + if (((oop)dmh)->is_oop()) { + oop dmh_oop = (oop) dmh; + if (java_lang_invoke_MemberName::is_instance(dmh_oop)) + member_name = dmh_oop; + else + // FIXME: delete this next line when InvokerBytecodeGenerator code shape is updated + member_name = java_lang_invoke_DirectMethodHandle::member(dmh_oop); + } thread->set_vm_result(member_name); } IRT_END
14-02-2014