United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 7056328 JSR 292 invocation sometimes fails in adapters for types not on boot class path
7056328 : JSR 292 invocation sometimes fails in adapters for types not on boot class path

Details
Type:
Bug
Submit Date:
2011-06-18
Status:
Closed
Updated Date:
2012-12-05
Project Name:
JDK
Resolved Date:
2011-07-18
Component:
hotspot
OS:
generic
Sub-Component:
compiler
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
7
Fixed Versions:
7

Related Reports
Backport:
JDK-2212514 - JSR 292 invocation sometimes fails in adapters for types not on boot class path
Backport:
JDK-2211017 - JSR 292 invocation sometimes fails in adapters for types not on boot class path
Backport:
JDK-2212515 - JSR 292 invocation sometimes fails in adapters for types not on boot class path
Relates:
JDK-7092712 - JSR 292: unloaded invokedynamic call sites can lead to a crash with signature types not on BCP
Relates:
JDK-7093796 - JSR 292: Rtalk test case fails with: NoClassDefFoundError: ri/core/rtalk/RtObject
Relates:
JDK-7093795 - JSR 292: Seph bench/bench_arithmetic.sp fails with: NoClassDefFoundError: seph/lang/SephObject
Relates:
JDK-7055941 - JSR 292 method handle invocation causes excessive deoptimization for types not on boot class path
Relates:
JDK-7082949 - JSR 292: missing ResourceMark in methodOopDesc::make_invoke_method

Sub Tasks

Description
When the server compiler spins an ad hoc bytecode adapter (in MethodHandleCompiler), this adapter can sometimes contain references to names not on the BCP.  If this adapter is deoptimized, and run in the interpreter, look of these names can fail.

Comments
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ddd894528dbc
2011-07-08 
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ddd894528dbc
2011-07-07 
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/81d815b05abb
2011-06-25 
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ddd894528dbc
2011-06-24 
SUGGESTED FIX

Each ad hoc adapter has its own constant pool, to give meaning to the bytecodes which must mention names.  This constant pool should be pre-resolved, coming out of MethodHandleWalk.  (MHW has all the live values it needs to do this.)  In particular, calls to MH.invoke and MH.invokeExact need to be resolved to customized invokers, with their own "live" MethodTypes.  Note that MethodTypes cannot in general be recovered from "flat" signature strings, unless the caller is in the correct class loader.  In the case of an ad hoc adapter, the loader is the BCP loader, which cannot see types outside the BCP.
2011-06-18 
WORK AROUND

Language runtimes should be placed on the BCP until these corner cases are worked out.
2011-06-18 
EVALUATION

Yes.
2011-06-18


Hardware and Software, Engineered to Work Together