[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