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

[Krystal Mo]

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