Request for review (M): JDK-7087570: java.lang.invoke.MemberName information wrong for method handles created with findConstructor

Christian Thalinger christian.thalinger at
Tue Feb 12 02:06:54 UTC 2013

On Feb 8, 2013, at 10:38 AM, Krystal Mo < at> wrote:

> Hi all,
> Could I have a couple of review for this change:
> 7087570: java.lang.invoke.MemberName information wrong for method handles created with findConstructor
> Summary: REF_invokeSpecial DMHs (which are unusual) get marked explicitly; tweak the MHI to use this bit
> Reviewed-by: ?
> Webrev:


+     static DirectMethodHandle make(Class<?> receiver, MemberName member) {
+         byte refKind = member.getReferenceKind();
+         if (refKind == REF_invokeSpecial)
+             refKind =  REF_invokeVirtual;
+         return make(refKind, receiver, member);
+     }

We are replacing all invokespecials with invokevirtuals?

-- Chris

> Bug:
> ( And a duplicate of this: )
> Background:
> When linking methods, HotSpot VM may strength-reduce the invocation mode of some virtual methods from invokevirtual to invokespecial.
> e.g. virtual methods in a final class, or non-private member methods marked as final.
> When that happens, a method's invocation mode may be nominally "invokevirtual", but the VM actually treats it as "invokespecial".
> Before this fix, the Java-level MethodHandle implementation didn't tell apart the "real" invokespecials with the strength-reduced ones. When creating a MethodHandle via lookup/ldc/unreflect, wrong metadata may be returned if this strength-reduction happened. This broke a few things, including the two scenarios in JDK-7087570 and JDK-8005119.
> With the fix, special handling is added so that a "real" invokespecial is truly a "Special" version of DirectMethodHandle, so users of the MethodHandle will not be affected by the mismatch between the nominal and the actual invocation mode.
> For the record, credit goes to John Rose who did the actual fix. I only added the unit test to verify the fix.
> Tested with JPRT, jtreg test/java/lang/invoke, including the new unit test.
> I intend to push this to jdk8/tl/jdk as it's a Java-only change; I believe langtool people could get the bits earlier this way.
> Could somebody from the jdk side help with the push?
> Thanks,
> Kris

More information about the core-libs-dev mailing list