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

[John Rose]

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