Request for reviews (M): 6939134: JSR 292 adjustments to method handle invocation

[John Rose]

I haven't heard any comments on the javac code changes for the JSR 292 method name changes, so I assume they are acceptable.  There are known bugs remaining for me to fix (such as 6868490) so if something strikes you about the way the new code is organized, there will be opportunities to fix it.

I took into account a comment Neal made last May about driving the front-end behavior from the -target option.  The result is cleaner.  I deleted a special twist in the javac.Main class, and added an explicit predicate (allowPolymorphicSignature) to the Source class.  

Here is the final webrev for this change:
  http://cr.openjdk.java.net/~jrose/6939134/lt-webrev.02/

-- John

P.S.  Although "polymorphic signatures" sounds like a huge language change, the new behavior applies only to the three special names in java/dyn specified by the JSR 292 EG.

Here are the corresponding JDK changes which introduce the polymorphic signatures.  The annotation (which is private) has to be present in order to elicit the new compiler feature:

  http://cr.openjdk.java.net/~jrose/6939134/jdk-webrev.02/src/share/classes/java/dyn/InvokeDynamic.java.udiff.html
  http://cr.openjdk.java.net/~jrose/6939134/jdk-webrev.02/src/share/classes/java/dyn/MethodHandle.java.udiff.html

The hole opened in the type system by polymorphic signatures is provably localized to java/dyn, and exactly matches the extended behavior of the JVM, for those special names.  Running new bytecodes on an old JVM will get a a verifier error or a linkage error, depending on the details of the case.

On Mar 31, 2010, at 4:02 PM, John Rose wrote:

> http://cr.openjdk.java.net/~jrose/6939134/lt-webrev.00
> 
> This review request is specifically for JVM changes.  They will be coordinated with the following JDK and javac changes:
> http://cr.openjdk.java.net/~jrose/6939134/hs-webrev.00/
> http://cr.openjdk.java.net/~jrose/6939134/hs-webrev.00/
> 
> Details:
> 
> 6939134: JSR 292 adjustments to method handle invocation
> Summary: split MethodHandle.invoke into invokeExact and invokeGeneric
> Mark the special signature-polymorpic methods and classes with @PolymorphicSignature.
> Reviewed-by: ?
> 
> The JSR 292 EG has decided to split MethodHandle.invoke into two
> methods, invokeExact and invokeGeneric.  Adjust javac so that it uses
> a marker annotation (@PolymorphicSignature) to recognize which methods
> are signature-polymorphic.  Remove hard-coded recognition of
> MethodHandle.invoke and InvokeDynamic.
>