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