Hi Vladimir, > Am 17.11.2015 um 13:08 schrieb Vladimir Ivanov <vladimir.x.iva...@oracle.com>: > Awesome! Looks really good, Michael!
thank you very much. > src/java.base/share/classes/java/lang/invoke/MethodHandles.java: > if (!hasPrivateAccess() > || (specialCaller != lookupClass() > + // ensure non-abstract methods in superinterfaces can > be special-invoked > + && !(refc != null && refc.isInterface() && > refc.isAssignableFrom(specialCaller)) > && !(ALLOW_NESTMATE_ACCESS && > > Is it a fix for an existing bug? If it's the case, I'd prefer to see it as a > stand alone fix. This is the implementation of the findSpecial capability to bind non-abstract methods in super interfaces, as mentioned in the JEP document. > src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java: > + static final MethodHandle MH_looper; > + static final MethodHandle MH_countedLoopPred; > + static final MethodHandle MH_countedLoopStep; > + static final MethodHandle MH_iteratePred; > + static final MethodHandle MH_initIterator; > + static final MethodHandle MH_iterateNext; > + static final MethodHandle MH_tryFinallyExec; > + static final MethodHandle MH_tryFinallyVoidExec; > > I think you have to adjust that part since Claes made MH constant > initialization lazy. Yes, Claes had given me a heads-up early on (thanks Claes!), and the merge was easy enough. The new webrev is here: http://cr.openjdk.java.net/~mhaupt/8139885/webrev.01/ > Also, does it make sense to provide bytecode intrinsics for tryFinally and > loop combinators in InvokerBytecodeGenerator to compile them in more > efficient bytecode shapes. If yes, please, file corresponding RFEs. Absolutely; this is on my to-do list anyway. https://bugs.openjdk.java.net/browse/JDK-8143211 Best, Michael -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
