United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7045513 JSR 292 inlining causes crashes in methodHandleWalk.cpp
JDK-7045513 : JSR 292 inlining causes crashes in methodHandleWalk.cpp

Details
Type:
Bug
Submit Date:
2011-05-17
Status:
Closed
Updated Date:
2011-08-02
Project Name:
JDK
Resolved Date:
2011-07-18
Component:
hotspot
OS:
generic
Sub-Component:
compiler
CPU:
generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
7
Fixed Versions:
hs21 (b14)

Related Reports
Backport:
Backport:
Backport:
Relates:
Relates:

Sub Tasks

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

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a80577f854f9
                                     
2011-05-18
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.
                                     
2011-05-19



Hardware and Software, Engineered to Work Together