On Jan 5, 2011, at 4:56 AM, Christian Thalinger wrote:

> I looked into this bug and the cause is that the method handles are not 
> verified.  Running with a debug build or using -XX:+UnlockDiagnosticVMOptions 
> -XX:+VerifyMethodHandles with a product build throws the excepted exception:

Thanks, Christian.

VerifyMethodHandles has detected that trusted JDK code has built a bad method 
handle.

> Caused by: java.lang.IllegalArgumentException: bad adapter 
> (conversion=0x00000100): type mismatch: returning a sun.dyn.empty.Empty, but 
> caller expects primitive boolean

The conversion code indicates an OP_RETYPE_RAW adapter.  The complaint is that 
it is adapting an Empty-valued MH to a boolean-valued one.  This is actually 
legal, because Empty is an "always null" type.  (See uses of 
is_always_null_type is methodHandles.cpp.)  More specifically, Empty is being 
returned because the MH itself is known to throw an exception always.  The raw 
adapter can retype the return type boolean (or any other type) with impunity.

So this is probably a case of false negative in VerifyMethodHandles.

> We have two problems here: (a) the conversion problem and (b) a lack of 
> checking (either the method handles itself or in the compiler).

The conversion may be OK.  The checking logic should be examined.

-- John
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Reply via email to