>> 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.)
