Adopting JEP 303 (Intrinsics for LDC and INVOKEDYNAMIC) into Amber

[Brian Goetz]

Some quick background on the putative benefits of this feature (and why 
we're investing in it):

  - Lazy constant loading.  Currently, constructing a Class, MethodType, 
or MethodHandle in a <clinit> forces eager class loading, which (a) 
contributes to startup and (b) potentially leads to bootstrap loops.  
Being able to express an LDC from nominal inputs in Java means constant 
resolution can be delayed with no loss of performance.

  - Indy.  Right now, there's no nonreflective way to encode an indy in 
Java source code. As we use indy more and more, this becomes an 
increasingly bigger problem, especially for testing.

  - Nominal carriers for bytecode and compiler plugin APIs. Bytecode 
APIs and compiler plugins need a way to describe classfile constants, 
both on the generation and parsing side.  The "live types" (Class, 
MethodType, MethodHandle) are unsuitable because the classes being 
described may not be loadable.  This forces API designers into ad-hoc 
encodings, either abusing strings, or defining one-off classes.

  - Static opt-out of indy-driven language features. As we have more 
language features that use indy (lambda, string concat, maybe soon 
switch classifiers), we need a way to opt out of using indy in targeted 
ways (globally for AOT, locally for bootstrap avoidance).  However, we 
don't want to force the compiler to understand the semantics of each 
bootstrap; ideally, bootstraps can be expressed in both nominal and 
"live" forms, and the compiler can choose which it wants.  If the types 
representable in in the constant pool have both live and nominal 
representations that can be freely converted to each other, this reduces 
the code duplication we might otherwise encounter in static-izing indy 
sites.  There's a long road to get here, but this is almost certainly 
part of the solution.