Awesome! Looks really good, Michael!

             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.

+        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.

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.

Best regards,
Vladimir Ivanov

On 11/13/15 7:39 PM, Michael Haupt wrote:
Dear all,

please review this change.
Corresponding JEP:




Oracle <>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
OracleJava Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam,
Green Oracle <>   Oracle is committed to
developing practices and products that help protect the environment

mlvm-dev mailing list

mlvm-dev mailing list

Reply via email to