Bug with invokeArguments on x64

John Rose john.r.rose at oracle.com
Tue Jan 4 16:25:48 PST 2011


On Jan 3, 2011, at 9:03 AM, Rémi Forax wrote:

> Hi Christian,
> 
> On 01/03/2011 05:41 PM, Christian Thalinger wrote:
>> On Dec 27, 2010, at 12:30 PM, Rémi Forax wrote:
>>> Hi guys,
>>> this code crash with jdk7b123 on x64,
>>> and on x32 it raises a CCE but it should raise a WrongMethodTypeException.
>> 
>> The crash should be fixed by:
>> 
>> 7007377: JSR 292 MethodHandlesTest.testCastFailure fails on SPARC with -Xcomp +DeoptimizeALot
>> 
>> which will be in HS20.0-b05.
>> 
>> But about the WrongMethodTypeException, why do you think that one should be thrown instead of a CCE?
> 
> because this is what the doc says:
> http://download.java.net/jdk7/docs/api/java/dyn/MethodHandle.html#invokeWithArguments%28java.lang.Object...%29
> 
>> -- Christian

The doc says three things:

1. ...as if via invokeGeneric from a call site which mentions only the type Object, and whose arity is the length of the argument array.

2. Because of the action of the asType step, the following argument conversions are applied as necessary: ... reference casting

3. Throws: WrongMethodTypeException - if the target's type cannot be adjusted to take the arguments

Point 2 is the source of the ClassCastException, which is correct.

A WMTE is thrown only if asType would also throw it.  (This should be made clearer.)

If there is no type-handler, the asType conversion can throw WMTE for arity mismatch or primitive narrowing, but it never throws WMTE just because of a reference type mismatch.

If there is a type-handler (this is a provisional, controversial feature) any method-type mismatch will be referred to the type-handler (as if via asType), and the type-handler takes responsibility for making up the mismatch or throwing WMTE.

-- John


More information about the mlvm-dev mailing list