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

[Christian Thalinger]

On Feb 8, 2013, at 10:38 AM, Krystal Mo <krystal.mo at oracle.com> 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: http://cr.openjdk.java.net/~kmo/7087570/webrev.00/

src/share/classes/java/lang/invoke/DirectMethodHandle.java:

+     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: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7087570
> ( And a duplicate of this: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005119 )
> 
> 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