[10] RFR (XS): 8194963: SystemDictionary::link_method_handle_constant() can't link MethodHandle.invoke()/invokeExact()

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Fri Jan 12 15:39:03 UTC 2018


http://cr.openjdk.java.net/~vlivanov/8194963/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8194963

It's a fix for a bug introduced by 8188145 [1].

MethodHandle.invoke()/invokeExact() have an implicit appendix argument 
(MethodType isntance) which is used for type checking method handle 
against call site.

MemberName resolution doesn't support such methods (with appendix 
argument), because there's no way to attach an appendix to MemberName.

Before 8188145, it was handled in JDK code [2], but now JVM performs 
MemberName resolution first before doing the upcall into JDK.

The fix is to avoid resolving those methods in 
SystemDictionary::link_method_handle_constant() (they are well-known, 
public, signature polymorphic) and only resolve method descriptor before 
doing the upcall.

Testing:
   * failing tests, jdk/java/lang/invoke
   * hs-precheckin-comp, hs-tier1, hs-tier2, jdk-tier1, jdk-tier2 (in 
progress)

Thanks!

Best regards,
Vladimir Ivanov

[1] https://bugs.openjdk.java.net/browse/JDK-8188145

[2] 
http://hg.openjdk.java.net/jdk/hs/file/bade224cc81e/src/java.base/share/classes/java/lang/invoke/MethodHandles.java#l2446
         MethodHandle linkMethodHandleConstant(byte refKind, Class<?> 
defc, String name, Object type) throws ReflectiveOperationException {
...
             // Treat MethodHandle.invoke and invokeExact specially.
             if (defc == MethodHandle.class && refKind == 
REF_invokeVirtual) {
                 mh = findVirtualForMH(member.getName(), 
member.getMethodType());
                 if (mh != null) {
                     return mh;
                 }
             }


More information about the hotspot-runtime-dev mailing list