Looks good.  Would be good to put a FIXME on the comment as well so we don’t 
forget to remove it.

On May 26, 2014, at 12:25 PM, Vladimir Ivanov <vladimir.x.iva...@oracle.com> 
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

Reply via email to