JDK-7045513 : JSR 292 inlining causes crashes in methodHandleWalk.cpp
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-05-17
  • Updated: 2011-08-02
  • Resolved: 2011-07-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 Other
7Fixed 8Fixed hs21Fixed
Related Reports
Relates :  
JDK-7047697 - MethodHandle.invokeExact call for wrong method causes VM failure if run with -Xcomp
Relates :  
JDK-6998541 - JSR 292 implement missing return-type conversion for OP_RETYPE_RAW
Description
This is a follow-up to 6998541.

Customers have observed that inlining some kinds of method handles tickles unexpected paths in methodHandleWalk.cpp.

Known cases:

- http://mail.openjdk.java.net/pipermail/mlvm-dev/2011-May/003060.html
- http://mail.openjdk.java.net/pipermail/mlvm-dev/2011-May/003055.html
- 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.
Comments
EVALUATION 7045513: JSR 292 inlining causes crashes in methodHandleWalk.cpp Reviewed-by: jrose 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.
19-05-2011
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a80577f854f9
18-05-2011