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