Crash in Compile::find_intrinsic

Christian Thalinger christian.thalinger at oracle.com
Fri Jan 7 02:48:01 PST 2011


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


More information about the mlvm-dev mailing list