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.

Wait a second...  I doubt this is a false negative in VerifyMethodHandles.  The 
MethodHandleWalker can't find a raw retype conversion function and that's why 
it crashes.  Maybe it is a false negative but then we are missing some 
conversion logic in the walker too.

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

Reply via email to