New JEP: Javac intrinsics for LDC and INVOKEDYNAMIC

[Brian Goetz]

> I like this JEP :)

I thought you might :)

It took us a long time to find a way of surfacing this feature that we 
like.  This is at least our fourth design iteration over several years; 
the others weren't worth sharing :)

> ldc:
>    i don't like having to use another constant hierarchy,
>    i would prefer to have static factories

Let's save the API design discussion for later -- right now, review 
comments should focus on the scope of the JEP.  But as a general goal, 
we're trying to keep the surface area of the intrinsified portion small 
-- right now, it's two methods (ldc and indy). Remember, this is an 
advanced tool for low-level programming; convenience methods may not be 
as needed as they might be with other APIs.

>    by example for constMethodHandle, the compiler
>    - requires all arguments to be constants
>    - emits an error if the underlying method do not exist or the tag is not valid, etc at compile time,
>    - replace the call with a ldc with the right constant pool constant if the constant is not constant-folded because it's part of another constant

The LDC intrinsification is the point at which we must enforce that we 
have a constant in hand.  The XxxConstant classes can freely tolerate 
non-constant content (perhaps they should be renamed), it's only when we 
want to intrinsify that a constant is truly needed.

>    - the BootstrapSpecifier should only contain a constant MethodHandle and an array of constant and a name, the descriptor should be computed by the compiler from the callsite, what @PolymorphicSignature already does.

That's a valid alternative (which we considered.)  Again, if the goal is 
to allow explicit control over indy, it seems preferable to put the 
MethodType in the indy descriptor -- as this more closely models the 
BootstrapMethods entry -- and have that take precedence -- and then we 
can type-check the call site (and adapt args/returns appropriately) 
against the "official" descriptor.

>    a counter-proposal, let say we have an empty class
>      class InvokedynamicCompilerIntrinsics {
>        // empty
>      }
>   
>    introduce a new syntax,

I understand why you want this, but .... no :)

It is an explicit anti-goal to have language syntax for this feature.  
(Finding an acceptable way to do this is part of why we had to wait this 
long.)  This is a feature for a few hundred people, at most.  Adding 
language surface for this would merely encourage the book authors / 
training providers of the world to include it (either because it seems 
new and cool, or out of a desire to be comprehensive) -- thereby 
exposing the other 99.9999% of the Java ecosystem to a feature they will 
never -- and should never -- use. (Balancing the needs of advanced 
developers while not polluting "everyone's Java" is a very difficult 
balance.)