review for 7045513: JSR 292 inlining causes crashes in methodHandleWalk.cpp

[Tom Rodriguez]

On May 17, 2011, at 4:46 PM, John Rose wrote:

> Comments:
> 
> 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.

Thanks!

tom

> 
> -- John
> 
> On May 17, 2011, at 4:01 PM, Tom Rodriguez wrote:
> 
>> http://cr.openjdk.java.net/~never/7045513
>> 335 lines changed: 277 ins; 8 del; 50 mod; 21338 unchg
>> 
>> 7045513: JSR 292 inlining causes crashes in methodHandleWalk.cpp
>> Reviewed-by:
>> 
>> 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.
>> 
>