review request (URGENT): 7047697: MethodHandle.invokeExact call for wrong method causes VM failure if run with -Xcomp

[John Rose]

7047697: MethodHandle.invokeExact call for wrong method causes VM failure if run with -Xcomp
http://cr.openjdk.java.net/~jrose/7047697/webrev.00/

The bug is that if a method handle stub must raise an error condition, and the method handle stub was called directly from compiled code, the transition from the compiled frame to the VM fails, because the existing code assumes that the call comes from an interpreter frame.

This bug shows up most reliably when run with "-client" and "-Xcomp".  Otherwise, it is sporadic.

When this bug is removed, another bug appears behind it.  There is a missing line of code in one of the constructors of class frame.  This causes the compiled frame (containing a method handle call) to be improperly parsed, because the _unextended_sp is not correctly initialized, specifically in the case of a method handle call from compiled code.

Details by file:

1. (assembler) The method handle stubs are generated from an InterpreterMacroAssembler.  But stubs can be called either from compiled or interpreted callers.  If a stub needs to call out to the JVM, it has to use the call_VM macro.  This macro should be the version from MacroAssembler, which is generic for all kinds of callers.

2. (frame) One of the x86 constructors for class frame failed to adjust the _unextended_sp field.  Add the subroutine which does this to the affected constructor.  (All others do.)  This constructor happens to be used for creating the caller of an entry_frame (used to represent a Java-to-VM call).

3. (methodHandles) When raising a WrongMethodTypeException directly from a method handle stub, do so directly using call_VM.  Do not use an interpreter stub.  (See #1 above.)

4. (pcDesc) When printing a PcDesc, print its tag bits.  (Used for investigating this bug.)