[9] RFR (XS): JSR 292 support for PopFrame has a fragile coupling with DirectMethodHandle

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Mon May 26 19:25:14 UTC 2014


Citing John's explanation of motivation for this change (from the bug):
"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."

Testing: JPRT, jtreg (java/lang/invoke), vm.mlvm.testlist


Best regards,
Vladimir Ivanov

More information about the hotspot-compiler-dev mailing list