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

[serguei.spitsyn at oracle.com]

Vladimir,

It looks good.

Thanks,
Serguei

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