JEP 303 vs JEP 348

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at 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 :)