RFR(L): 8139885: implement JEP 274: enhanced method handles

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Tue Nov 17 12:08:38 UTC 2015


Awesome! Looks really good, Michael!

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.

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.

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.
> RFE: https://bugs.openjdk.java.net/browse/JDK-8139885
> Corresponding JEP: https://bugs.openjdk.java.net/browse/JDK-8130227
> Webrev: http://cr.openjdk.java.net/~mhaupt/8139885/webrev.00/
>
> Thanks,
>
> Michael
>
> --
>
> Oracle <http://www.oracle.com/>
> 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,
> Germany
> Green Oracle <http://www.oracle.com/commitment>	Oracle is committed to
> developing practices and products that help protect the environment
>
>
>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>


More information about the mlvm-dev mailing list