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

serguei.spitsyn at oracle.com serguei.spitsyn at oracle.com
Wed May 28 05:37:18 UTC 2014


It looks good.


On 5/26/14 12:25 PM, Vladimir Ivanov wrote:
> https://bugs.openjdk.java.net/browse/JDK-8034935
> http://cr.openjdk.java.net/~vlivanov/8034935/webrev.00
> 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
> Thanks!
> Best regards,
> Vladimir Ivanov

More information about the hotspot-compiler-dev mailing list