review request (L): 6981777 implement JSR 292 EG adjustments from summer 2010

[Tom Rodriguez]

Looks ok.

tom

On Sep 12, 2010, at 3:11 AM, John Rose wrote:

> 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.