On May 18, 2017, at 12:55 PM, John Rose <john.r.r...@oracle.com> wrote:
>  I'll post some info about that in a moment.

Here's what we are thinking about doing with condy in the short term.
Comments are welcome.  This work is landing in branches of the Amber

— John

Just as the linkage of an invokedynamic call site involves an upcall
from the JVM to Java-based linkage logic, we can apply this same trick
to the resolution of a constant pool entry. A CONSTANT_Dynamic
constant pool entry encodes the bootstrap method to perform the
resolution (a MethodHandle), the type of the constant (a Class), and
any static bootstrap arguments (an arbitrary sequence of constants,
barring cycles in the CP between dynamic constants.)

We add a new constant pool form, CONSTANT_Dynamic (new constant tag
17), which has two components following its tag byte: the index of a
bootstrap method, in the same format as the index found in a
CONSTANT_InvokeDynamic, and a CONSTANT_NameAndType) which encodes the
expected type.

Behaviorally, a CONSTANT_Dynamic constant is resolved by executing its
bootstrap method on the following parameters: 1. a local Lookup
object, 2. the String representing the name component of the constant,
3. the Classrepresenting the expected constant type, and 4. any
remaining bootstrap arguments. As with invokedynamic, multiple threads
can race to resolve, but a unique winner will be chosen and any other
contending answers discarded. Instead of returning a CallSite object
(as the invokedynamicinstruction requires) the bootstrap method would
return a value which would be immediately converted to the required

As with invokedynamic, the name component is an additional channel,
besides the type, for passing expression information to the bootstrap
method. It is expected that just as invokedynamic instructions find
uses for the name component (e.g., a method name or some ad hoc
descriptor) dynamic constants will also find uses for the name (e.g.,
the name of a enum constant or the spelling of a symbolic
constant). Putting the CONSTANT_NameAndTypein both places makes for a
more regular design. In effect, a CONSTANT_Methodref and
CONSTANT_Fieldref constants are used to refer to named members of
classes, while the analogous CONSTANT_InvokeDynamic and
CONSTANT_Dynamic constants are used to refer to named entities with
user-programmed bootstraps.

The type component of the constant, with both invokedynamic
andCONSTANT_Dynamic, determines the effective type of the call site or
constant (respectively). The bootstrap method does not contribute or
constrain this type information, so that bootstrap methods may be (and
often are) weakly typed whereas the bytecodes themselves are always
strongly typed.

To relax length restrictions on bootstrap specifiers, the language
which defines the invocation of bootstrap methods will be adjusted
(with complete backward compatibility) to allow variable arity
(ACC_VARARGS) bootstrap methods to absorb, into their trailing
arguments, all remaining static arguments, even if there are 2^16-1 of
them. (The classfile format already allows this, although there is no
way to read over-long bootstrap argument lists.) For consistency, the
invokeWithArguments methods of MethodHandle will also be expanded in
this way, if the target method has variable arity. In this way the
invocation of bootstrap methods can be specified in terms of the
weakly typed methods invokeWithArguments and invoke, just as today it
is specified in terms of invoke alone.

mlvm-dev mailing list

Reply via email to