JDK-7056328 : JSR 292 invocation sometimes fails in adapters for types not on boot class path
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-06-18
  • Updated: 2012-12-05
  • 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
7 b147Fixed 8Fixed hs21Fixed
Related Reports
Relates :  
JDK-7082949 - JSR 292: missing ResourceMark in methodOopDesc::make_invoke_method
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-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
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
08-07-2011
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ddd894528dbc
07-07-2011
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/81d815b05abb
25-06-2011
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ddd894528dbc
24-06-2011
EVALUATION Yes.
18-06-2011
WORK AROUND Language runtimes should be placed on the BCP until these corner cases are worked out.
18-06-2011
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.
18-06-2011