JDK-6939134 : JSR 292 adjustments to method handle invocation
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 7
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2010-03-30
  • Updated: 2017-05-16
  • Resolved: 2010-05-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u21pFixed 7Fixed hs19Fixed
Related Reports
Duplicate :  
JDK-6954108 - DYN_REGRESSION suite fails with "Invalid layout of preloaded class"
Relates :  
JDK-6948673 - Update SourceVersion.isIdentifier to account for JSR 292 exotic identifiers
Relates :  
JDK-6979327 - method handle invocation should use casts instead of type parameters to specify return type
Relates :  
JDK-6918897 - No appropriate CCC request for listed JDK 7 changes in java.dyn package (b79)
Relates :  
JDK-6949830 - 6939134 broke Zero
Description
The JSR 292 EG has decided to split MethodHandle.invoke into two methods, invokeExact and invokeGeneric.  The EG has also decided to simplify the process of CallSite bootstrapping.  These changes require updates to the toolchain and JVM.

This bug is the first part of a two part change.  This change updates the CallSite API.  It renames MH.invoke to invokeExact and introduces invokeGeneric as a separately recognized operation, but does not give the two operations distinct semantics.  A following bug will give invokeGeneric its distinct semantics.
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/cd5dbf694d45
01-05-2010
SUGGESTED FIX *** change notes for langtools repo: Summary: split MethodHandle.invoke into invokeExact and invokeGeneric Mark the special signature-polymorphic methods and classes with @PolymorphicSignature. The JSR 292 EG has decided to split MethodHandle.invoke into two methods, invokeExact and invokeGeneric. Adjust javac so that it uses an empty attribute 'PolyMorphicSignature' to recognize which methods are signature-polymorphic. Drive emission of this attribute from a package-private annotation (@PolymorphicSignature). Remove hard-coded recognition of MethodHandle.invoke and InvokeDynamic. For the relevant parts of the language specification, see: http://wikis.sun.com/display/mlvm/InterfaceDynamic *** change notes for jdk repo: Summary: split MethodHandle.invoke into invokeExact and invokeGeneric; also clean up JVM-to-Java interfaces The JSR 292 EG has decided to split MethodHandle.invoke into two methods, invokeExact and invokeGeneric. The EG has also decided to simplify the process of CallSite bootstrapping. These changes coordinate with updates to the javac and the JVM. Rename MH.invoke to invokeExact and introduce invokeGeneric as a separately recognized operation. Mark all special signature-polymorpic methods and classes with the annotation @PolymorphicSignature, which is specially recognized by javac. Include API adjustments recently requested by the JSR 292 EG. There are a number of deprecated methods, which will be removed for the final release. Some previously deprecated methods are already removed in this update. Changes include: - CallSite: Deprecate multi-argument constructor, for imminent removal. - CallSite: Deprecate accessors for caller class, name, and type, for imminent removal. - CallSite: Remove superclass. - Linkage: Adjust to simplified CallSite constructor, but take more information privately from the JVM. - MethodHandle: Deprecate invoke; introduce invokeExact and invokeGeneric. - MethodHandle: Make invokeVarargs be (well) a varargs method. - MethodHandles.Lookup: Tighten up all the access checking logic. Factor the code better. - MethodHandles: Remove previously deprecated methods (methodType aliases). - sun/dyn/*: Change MH.invoke to MH.invokeExact, in hundreds of places. - MemberName: Allow limited wildcarding of member lookup (type=null and/or name=null). - MethodHandleImpl: Factor some ad hoc logic out of findMethod and into MethodHandles.lookup. - MethodTypeImpl: Correct a backwards permutation in reorderParameters. - sun/dyn/util/VerifyAccess: Rework access checking to conform to JVM documentation (now cited in javadoc). - MethodHandlesTest: Update unit tests. Add more cases for API usage and access checking. - Update and clarify javadoc for affected classes and in package-info files. Specific changes to the private interface between the JVM and Java code: - Move misc. upcalls to a single implementation-private interface class, MethodHandleNatives. - Reduce the VM's entanglement with CallSite by removing some hardwired fields from CS. - Pass more information to the Java code when bootstrapping a CallSite. - Obtain MethodHandleNatives.CONV_OP_IMPLEMENTED_MASK from the JVM, which knows the correct mask. - Use only the JVM to store bootstrap methods, not a Java-level hash table. *** change notes for hotspot repo: Summary: split MethodHandle.invoke into invokeExact and invokeGeneric; also clean up JVM-to-Java interfaces The JSR 292 EG has decided to split MethodHandle.invoke into two methods, invokeExact and invokeGeneric. The EG has also decided to simplify the process of CallSite bootstrapping. These changes require updates to the toolchain and JVM. This bug is the first part of a two part change. This change updates the CallSite API. It renames MH.invoke to invokeExact and introduces invokeGeneric as a separately recognized operation, but does not give the two operations distinct semantics. A following bug will give invokeGeneric its distinct semantics. Changes to be done in this part include: - Recognize signature-polymorphic methods MH.invoke* and InDy.* via special IDs vmIntrinsics::_invoke*. - Make the vmSymbols::SID visible through the ciSymbol API. - Adding some mode bits to the key of SymbolPropertyTable (to distinguish invokeExact/invokeGeneric). - Improve the debug printing code for methodOop (notably, to show intrinsic ID). - Remove unused arguments and dead code. Specific changes to the private interface between the JVM and Java code: - Move misc. upcalls to a single implementation-private interface class, MethodHandleNatives. - Reduce the VM's entanglement with CallSite by removing some hardwired fields from CS. - Pass more information to the Java code when bootstrapping a CallSite. - Obtain MethodHandleNatives.CONV_OP_IMPLEMENTED_MASK from the JVM, which knows the correct mask. - Use only the JVM to store bootstrap methods, not a Java-level hash table. - Adjust access checks (under VerifyMethodHandles) for Direct MHs and MemberNames, to reduce test failures in debug mode.
01-05-2010
SUGGESTED FIX http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/78a0c933140f/meth-ing.patch Changes to be done in this part include: - Recognize signature-polymorphic methods MH.invoke* and InDy.* via special IDs vmIntrinsics::_invoke*. - Make the vmSymbols::SID visible through the ciSymbol API. - Adding some mode bits to the key of SymbolPropertyTable (to distinguish invokeExact/invokeGeneric). - Improve the debug printing code for methodOop (notably, to show intrinsic ID). - Remove unused arguments and dead code. Specific changes to the private interface between the JVM and Java code: - Move misc. upcalls to a single implementation-private interface class, MethodHandleNatives. - Reduce the VM's entanglement with CallSite by removing some hardwired fields from CS. - Pass more information to the Java code when bootstrapping a CallSite. - Obtain MethodHandleNatives.CONV_OP_IMPLEMENTED_MASK from the JVM, which knows the correct mask. - Use only the JVM to store bootstrap methods, not a Java-level hash table. - Adjust access checks (under VerifyMethodHandles) for Direct MHs and MemberNames, to reduce test failures in debug mode.
30-03-2010