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
