6981777: implement JSR 292 EG adjustments from summer 2010
Summary: Introduce one more constant pool type, CONSTANT_MethodApply.

This JVM change implements a mechanism which supports computed constants and 
parameterized bootstrap methods:
  http://cr.openjdk.java.net/~jrose/6981777/webrev.00

The JVM change supplies a "hook" for memoizing library-defined constants in the 
constant pool.

The actual semantics of the hook (which combines a "function" constant with an 
"argument" constant) will be defined by a JDK runtime routine which invokes the 
function on the argument if it is a unary function, and otherwise calls 
MethodHandles.bindTo, effectually treating the function as if it were curried.  
The code will be something like:
  apply(fun,arg) := fun.type.parameterCount == 1 ? fun.invokeGeneric(arg) : 
fun.bindTo(arg);

Combined with the pre-existing CONSTANT_MethodHandle constant pool entries, 
this provides a way to get a wide variety of computed constants.

Although it may seem odd to allow only one argument (and use the bindTo 
function to collect multiple arguments) this design matches better with the 
binary constant pool structure already commonly built into JVMs, including both 
the HotSpot and IBM JVMs.

The JVM change includes logic to ensure that if the initial computation of a 
constant causes an exception, this exception will be uniformly thrown from all 
points where it is referenced.   This logic applies to pre-existing constants 
also.

Motivation:  Parameterized bootstrap methods seem to be required for factoring 
closures and similar data structures into distinct static and dynamic 
specifications.  The computed constants allow explicit one-time computation of 
static information, to be used by an ldc or a bootstrap method or both.  Such 
"live constants" were a request from dynamic language implementors at the 
Summit.

A key use case for one-time computation appears to be representation selection 
for closures.  This is best done in a runtime (decoupled from the bytecode 
compiler), but should not be done on every closure creation.  The invokedynamic 
instruction can use bootstrap methods with additional parameters supplied by 
this mechanism to combine prepared closure bodies with closure parameters.  The 
same pattern can also be used by other language implementations which also need 
to combine static with dynamic data.

-- John

P.S. I expect one more significant JVM change coming this week:  It is the hook 
for MethodHandles.invokeGeneric, which enables the JVM to perform dynamic 
argument transformations during method handle invocations.
_______________________________________________
mlvm-dev mailing list
[email protected]
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Reply via email to