Extend the Java class-file format to support a new constant-pool form,
CONSTANT_Dynamic. Loading a
CONSTANT_Dynamic will delegate creation
to a bootstrap method, just as linking an
invokedynamic call site
delegates linkage to a bootstrap method.
We seek to reduce the cost and disruption of creating new forms of materializable class-file constants, which in turn offers language designers and compiler implementors broader options for expressivity and performance. We do so by creating a single new constant-pool form that can be parameterized with user-provided behavior, in the form of a bootstrap method with static arguments.
We will also adjust the link-time handshake between the JVM
and bootstrap methods, so as to adapt the bootstrap API used by
invokedynamic to apply also to dynamic constants.
Based on experience with
invokedynamic we will make adjustments to
the bootstrapping handshake of both
invokedynamic and dynamic
constants, loosening certain restrictions on the processing of
argument lists to bootstrap methods.
This work requires some prototyping of JDK library support for a representative sample of a few kinds of constant types, notably variable handles [(JEP 193)|193]. In support of such prototyping, this work will coordinate with other work on basic language support for constant expressions ([JEP 303|303]).
This JEP aims to support arbitrary constants in the constant pool. Although there are proposals for still other uses of bootstrap methods, such as method recipes, this JEP concentrates on one use.
The success of this JEP does not depend on support from the Java language or the Java compiler backend, although it is more likely to succeed if it is used by the compiler backend.
Although large aggregate constants are a weak point in Java's translation strategy, this JEP cannot solve for aggregates until there are better ways to encapsulate them in constant forms, such as frozen arrays or primitive-specialized lists.
As a minimal requirement, it should be practical to expose constant-pool
forms to describe primitive class mirrors (
constants, and most forms of
VarHandle in terms of
Dynamic constants must be usable in any context which currently
allows general constant pool constants, such as
CONSTANT_MethodType. Thus, they must be valid operands to
ldc instruction and must be allowed as static parameters
to bootstrap methods.
The bootstrap-method handshake should support complex constants which contain thousands of component arguments, lifting the current limit of 251 constant arguments. As a stretch goal, there should also be a way for the bootstrap method to more accurately control linkage errors produced by resolving bootstrap method arguments.
At the end of the work we should also have cause to believe that this mechanism can be made to work for a wide variety of library types, such as derived method handles, small immutable collections (lists, maps, sets), numerics, regular expressions, string formatters, or simple data classes.
Followup work should be identified and documented. See "Possible extensions" below.
Section 4.4 of the Java Virtual Machine Specification describes the
format of the constant pool. Adding new constant-pool forms, such as
the support for
MethodType introduced in Java 7,
is a significant endeavor, and sends ripples through the ecosystem, as
it affects all code that parses or interprets class files. This
presents a very high bar to creating new constant-pool forms.
invokedynamic, the value of storing complex data in the
constant pool is multiplied, since the static argument list for an
invokedynamic bootstrap is a sequence of constants. Designers of
invokedynamic protocols (such as the
LambdaMetafactory added in
Java 8) routinely struggle with the need to encode behavior in terms
of the existing constant set—which in turn necessitates additional
error-prone validation and extraction logic in the bootstrap itself.
Richer, more flexible, more highly-typed constants remove friction
from the development of
invokedynamic protocols, which in turn
facilitates the movement of complex logic from run time to linkage
time, improving program performance and simplifying compiler logic.
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-pool entry encodes the bootstrap method to perform the
MethodHandle), the type of the constant (a
and any static bootstrap arguments (an arbitrary sequence of
constants, barring cycles in the constant pool between dynamic
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
encodes the expected type.
CONSTANT_Dynamic constant is resolved by executing
its bootstrap method on the following parameters: 1. a local
object, 2. the
String representing the name component of the
constant, 3. the
Class representing the expected constant type,
and 4. any remaining bootstrap arguments. As with
multiple threads can race to resolve, but a unique winner will be
chosen and any other contending answers discarded. Instead of
CallSite object, as the
requires, the bootstrap method would return a value which would be
immediately converted to the required type.
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).
CONSTANT_NameAndType in both places makes for a more
regular design. In effect,
CONSTANT_Fieldref constants are used to refer to named members of
classes, while the analogous
CONSTANT_Dynamic constants are used to refer to named entities
with user-programmed bootstraps.
The type component of the constant, with both
CONSTANT_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 class-file 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
invoke, just as today
it is specified in terms of
Control of bootstrap linkage errors has proven to be a recurring
source of bugs and RFEs from users of
invokedynamic and the trend is
likely to accelerate as bootstrap methods become more complex (as they
must, with dynamic constants). If we can find a way to offer fuller
control over exceptions to bootstrap methods, and it can be done
simply, we will consider delivering it as part of this JEP.
Otherwise, it will go on the list of future enhancements.
Possible future extensions include:
- Support for bulk-scale constants such as arrays or resource tables
- Further adjustments to the bootstrap-method handshake
- Other uses of bootstrap methods which may synergize with dynamic constants
- Attaching dynamic constants to the
ConstantValueattribute of static fields
- Surfacing the lazy initialization of constants in the Java language
- Integrating new constants with special Java language rules for constant expressions
Discussion of design choices can be found in JDK-8161256, which deals with a number of related RFEs. The present JEP was distilled from this larger list of features.
Many uses of
CONSTANT_Dynamic can be replaced by equivalent
invokedynamic calls. (The call would take zero arguments and be
bound to a method handle that returns the desired constant.) Such a
workaround does not helps with a key requirement, however, which is
to be able to pass synthetic constants as bootstrap arguments.
Another alternative to
CONSTANT_Dynamic is using
fields to name the desired constants, and computing their values in
the static initializer (
<clinit>). This approach requires extra
metadata (a throwaway field definition per constant) and is not lazy
enough to avoid bootstrap cycle problems. Those problems are
routinely solved by building private nested classes with decoupled
static initializers, but that too requires extra metadata. If
languages evolve to use many such constants, there will be application
bloat from the excessive metadata.
Another approach is spinning static methods which perform the constant
elaboration logic, and then calling them lazily from
Again, such throwaway methods are a metadata overhead which is large
In practice the metadata overheads for simulating these features are too large.
This feature is JVM-centric, and so does not depend on higher software layers.
In order to ensure correct design, it requires at least experimental adoption by several use cases. Library prototyping is a must, even if the prototypes are thrown away.
invokedynamic, wide adoption requires use by the
end, which in turn may require language extensions. As a basic first
step, translation workarounds which require hidden static methods, such
as translation of
int.class or switch mapping tables should be examined
and reformulated with new constants, if possible.