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

[Krystal Mo]

Thank you for the review, Chris. Comments inline:

On 02/11/2013 06:06 PM, Christian Thalinger wrote:
>
> 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

This might look a bit hacky...

The idea is, DirectMethodHandle.make(Class<?> receiver, MemberName 
member) should keep its behavior as it used to be.

The newly added DirectMethodHandle.make(byte refKind, Class<?> receiver, 
MemberName member) treats (refKind == invokespecial) "specially", which 
is necessary when called from MethodHandles.getDirectMethodCommon(...), 
where invokevirtual got strength-reduced to invokespecial matters;
but when called from DirectMethodHandle.make(Class<?> receiver, 
MemberName member), refKind would need to be something other than 
invokespecial to keep the original behavior, thus the normalization in 
DirectMethodHandle.make(Class<?> receiver, MemberName member). This is safe.

Let's get John's comment and see if my understanding of that part is 
correct.

Thanks,
Kris

>> 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