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

[Bertrand Delsart]

Hi John,

Looks OK... but I'm concerned for ARM.

This fix involves fixes in x86 code, which is mirrored in ARM. Hence, 
even if the QA has not yet filed the bug for ARM, I expect we have the 
same issue (my understanding is that this also applies to C1).

I've seen on the CR comments that this is might have caused JCK failures.

Do you confirm that it lead to JCK failures, which we may be forced to 
solve for ARM ?

Bertrand.

On 06/ 8/11 12:49 PM, John Rose wrote:
> 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.)
>


-- 
Bertrand Delsart,               bertrand.delsart at oracle.com,
Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot,
38334 Saint Ismier,                                  FRANCE