On Jan 6, 2011, at 3:16 AM, John Rose wrote:
> 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.

Can you look at the false negative?  I will fix the checking logic.

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

Reply via email to