review for 7045513: JSR 292 inlining causes crashes in methodHandleWalk.cpp
tom.rodriguez at oracle.com
Tue May 17 16:48:18 PDT 2011
On May 17, 2011, at 4:46 PM, John Rose wrote:
> Assert-rich code. Very nice; thanks!
> This maybe could use assert(args_size >= 0) in emit_bc:
> + case Bytecodes::_invokeinterface:
> + _bytecode.push(args_size);
actually it should be > 0 since it must at least equal 1 for the receiver.
> Reviewed. I feel much better about MH compilation now.
> -- John
> On May 17, 2011, at 4:01 PM, Tom Rodriguez wrote:
>> 335 lines changed: 277 ins; 8 del; 50 mod; 21338 unchg
>> 7045513: JSR 292 inlining causes crashes in methodHandleWalk.cpp
>> Several issues with the MethodHandleWalk code were identified with
>> jruby and a stress mode was added that exposed quite a few more.
>> Method handles with void returns weren't being handled properly with
>> spreading. Constant ArgTokens weren't being handled in several
>> places. ArgToken didn't have enough asserts to guard against improper
>> use to handle could be mistakenly used as a local index. make_fetch
>> which was used by argument spreading wasn't implemented. Several of
>> the bytecodes didn't handle their proper u2 or u4 ranges. make_invoke
>> didn't sanity check the number of arguments passed. Dispatch through
>> invokeinterface was unimplemented. tail_call make_invokes didn't push
>> the result on the stack resulting in the max_stack on the method being
>> wrong. Currently I'm swallowing any exceptions thrown by the stress
>> logic but eventually those will need to be clean.
>> Tested with the java/lang/invoke regression tests with
>> StressMethodHandles turned on plus the failing jruby tests.
>> I fixed some ifdefs so that the optimized build works again.
>> I also added the richochet blob to the SA so that it can walk the code
>> cache. I had to add the AdapterBlobs as well.
More information about the hotspot-compiler-dev