----- Mail original ----- > De: "Brian Goetz" <brian.go...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> > Envoyé: Jeudi 14 Février 2019 13:48:24 > Objet: Re: JEP 303 vs JEP 348
>>> 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 goal is to provide intrinsics for ldc and indy, the notion of intrinsifiable constants is just a medium proposed by 303 to achieve that goal. I think it's a nice addition and not a core part. > > The intrinsic for indy() is useless without the broader form, but we can > optimize String.format just fine without it. "useless" is a strong word here, you are loosing the folding property, not more. > >>> 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 :) I think you are optimistic here, JEP 303 may never ship. Let me remember you your own argument against having a Java syntax for indy: the economics are against it, indy is used by a very few hundreds of Java devs, several orders of magnitude less than the number of people that are using Java. > > 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. Better is sometimes an enemy. If you have the constant folding wrong, you will get an exception at runtime. And i believe that in most case people will store IndyRefs inside static final fields for the same reason you have java.lang.constant.ConstantDescs, so the actual meaning of "constant" may be enough. > >> 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.) I'm fine with frustrating few people about what the feature could have been if it makes that feature being delivered*. And the true is that storing an IndyRef in a static final field is not that awful compared to what we have to do now. Moreover i believe we can still add the constant folding later after Intrinsics.invokedynamic has being delivered. It will make a runtime error a compile error which is not a backward compatible change but it's equivalent of generifying an API call used only by some happy few. Rémi * weirdly our roles are inverted in this discussion, i should be the academics guy :)
