This is a follow-up to 6998541.
Customers have observed that inlining some kinds of method handles tickles unexpected paths in methodHandleWalk.cpp.
- asSpreader adapters
There should be "lose" calls on paths we don't expect, so the method handle walker can back out cleanly and fail the inlining.
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.