review for 7045513: JSR 292 inlining causes crashes in methodHandleWalk.cpp
John Rose
john.r.rose at oracle.com
Tue May 17 16:46:00 PDT 2011
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);
Reviewed. I feel much better about MH compilation now.
-- 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.
>
More information about the hotspot-compiler-dev
mailing list