review request (M): 7056328: JSR 292 invocation sometimes fails in adapters for types not on boot class path

[John Rose]

Final update:
  http://cr.openjdk.java.net/~jrose/7056328/webrev.02

Found one more path (which you Tom pointed out a few days ago!) along which the constant pool needs to be passed, in order to properly scope JSR 292 method lookups.  This appears to really fix Ola's NoClassDefFound bug, even when indy code is compiled and then deoptimized.

Cumulative diffs:
  http://cr.openjdk.java.net/~jrose/7056328/webrev.02/00-to-02.diff

(The last missing bit was in linkResolver.cpp.)

-- John

On Jun 23, 2011, at 12:48 AM, John Rose wrote:

> On Jun 23, 2011, at 12:21 AM, John Rose wrote:
> 
>> I'm working through several small bugs that the stress test uncovered.  Will repost my webrev when done.  -- John
> 
> Here's the update:
>  http://cr.openjdk.java.net/~jrose/7056328/webrev.01
>  http://cr.openjdk.java.net/~jrose/7056328/webrev.01/00-to-01.diff
> 
> Stress testing uncovered a number of small bugs that are eventually going to bite us when users create invokedynamic bindings that get compiled, if those bindings use method handle graphs similar to those in the unit tests.
> 
> - JVM_CONSTANT_Object entries not handled by sparc and x86 interpreters (hazard after deoptimization of JIT-ed indy instructions)
> - collect/fold adapters call their recursive MH using relaxed typing (erased signatures), which is tricky to represent in bytecodes
> - bytecode for spread adapters unpacked the arguments in reverse!
> - ldc(X.class) should use JVM_CONSTANT_Class, not JVM_CONSTANT_Object
> - preloading of CP-cache entries is different for static and non-static methods
> 
> These bugs did not arise earlier apparently because the output of the method handle walker (which produces bytecode-based IR for the JIT) is only lightly exercised.  The best we had before was -client -Xcomp, but we don't have many in-house tests that compile constant graphs of MHs.  The best source of such patterns is external language engines like Charlie's and Ola's.
> 
> In the long term, we need something like -Xcomp to test method handles.
> 
> -- John