JEP 303 vs JEP 348

[Brian Goetz]

>> For JEP 348, this is an opportunistic
>> optimization; for 303, it is essential functionality (the call can’t proceed
>> un-intrinsified.)  And, for the indy() intrinsic, it simply cannot live without
>> the constant folding and propagation.  So separating those aspects is not
>> practical.
> 
> yes, on paper, but for JEP 348 you also need to know if the arguments of an intrinsics are constant or not.

Silly Remi, you’ve gotten confused by the difference between “constant” and “constant” :)

JEP 303 defines a broader, separate notion of “intrinsifiable constant”, which is deliberately different from “constant expression”.   JEP 348 only needs to know about the weaker, already-present notion of constant expression.  

The intrinsic for indy() is useless without the broader form, but we can optimize String.format just fine without it.

>> The two differ dramatically in their spec impact, as well.  348 requires little
>> more than permission to redirect the translation for specific methods; 303 is
>> much more deeply intrusive.
> 
> We can pull the VarHandle trick !
> Instead of specifying the semantics of Intrinsics.ldc/invokedynamic in the JLS which is as you said intrusive, you can move the spec part in the javadoc by transforming the compile time error to a runtime one.
> If the arguments of Intrinsics.ldc/invokedynamic are not constant, the compiler can still generate an indy call that will verify at runtime that the arguments are constants (technically by verifying that methods are always called with the same instances doing pointer checks). So we have moved compile errors to runtime errors which is objectively bad but we have at the same time avoided big change of the JLS by transforming Intrinsics.ldc/invokedynamic to API point only.

Ah, now you reveal your actual goal — to ship the indy() intrinsic sooner :)  I really wish you’d lead with this stuff :)  

This is a clever trick, but results in a measurably worse feature, since with constant folding it is easy to get wrong, and getting compile-time help is pretty valuable.  

> We may still need enhanced constant folding but that's another concern.

No, you will absolutely need enhanced folding to make it work; making an IndyRef requires making MethodTypeRefs, MethodHandleRefs, etc.  (And even if we tried to special-case the “build it all at once” case, without error messages at compile time to tell you when you messed up, it would be a very frustrating feature to use.)