Re: Updated Constables and constant folding doc

2018-03-12 Thread Brian Goetz
> the way the constant folding is done in this proposal scare me a lot,

It should scare you, it means you are reading ...

> pre-linking is usually a bad idea when done in the compiler because it means 
> that the world the compiler sees and the world VM sees has to be exactly the 
> same,

Yes, it means that the bar for @Foldable/Constable is very, very high.

> and there is nothing in the spec that guarantee that the compiler and the VM 
> are the same.

It means that the implementation of the @F/C classes must guarantee this.

Because of all the constraints, its use will be limited to java.base.





Re: Updated Constables and constant folding doc

2018-03-12 Thread Remi Forax
- Mail original -
> De: "Remi Forax" <fo...@univ-mlv.fr>
> À: "Brian Goetz" <brian.go...@oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net>
> Envoyé: Mardi 13 Mars 2018 00:10:43
> Objet: Re: Updated Constables and constant folding doc

> Hi Brian,
> the way the constant folding is done in this proposal scare me a lot,
> pre-linking is usually a bad idea when done in the compiler because it means
> that the world the compiler sees and the world VM sees has to be exactly the
> same,
> and there is nothing in the spec that guarantee that the compiler and the VM 
> are
> the same.
> 
> I've already be beaten badly by smart compilers in the past, if you have a bug
> in one constant folded method, you have as many bugs as the number of class
> files generated by the compiler.
> 
> We already have that bug that static final constants that are resolved at
> compile time instead of at runtime. i see your proposal as a way to add more
> bugs.
> 
> We have ConstantDynamic which is a way to do an arbitrary evaluation of a 
> value
> at runtime and consider it as a constant. This has the advantage of doing the
> constant folding at runtime. Doing the constant folding at runtime is 
> obviously
> slower but it eliminates a whole class of bugs.
> It works that way, when a method is marked at @ConstantFoldable, the compiler
> will create a synthetic method (like with a lambda) that will be used to
> initialize the condy.
> By example,
>  String s = `a long multi-
>line string`.trimIndent();
> is compiled to
>  ldc Condy String ConstantFoldableMetaFactory [constantFoldable$0 as a 
> constant
>  method handle]
> with
>  private static String constantFoldable$0() {
>return  `a long multi-
>line string`.trimIndent();
>  }
> 
> with the bsm of ConstantFoldableMetaFactory calling the constant method handle
> sent as bootstrap argument after having verified it was created from the same
> lookup as the one sent as first argument of the BSM.
> 
> This also avoid to have the compiler executing an arbitrary code.
> 
> Note: in the section decapturing of lambda, the 'prefix' is called 'p' inside 
> of
> the lambda.
> 

and i forget to say to jlink can be used to really do the constant folding by 
simplifying the ldc condy if the BSM is the one from 
ConstantFoldableMetaFactory,
because at jlink time, you know the exact version of Java that will be used at 
runtime. 

> Rémi
> 
> - Mail original -
>> De: "Brian Goetz" <brian.go...@oracle.com>
>> À: "amber-spec-experts" <amber-spec-experts@openjdk.java.net>
>> Envoyé: Lundi 12 Mars 2018 22:53:21
>> Objet: Updated Constables and constant folding doc
> 
>> I've updated the document on the ConstantRef / Constable API, and added
>> more detail on constant folding and propagation optimizations:
>> 
> >      http://cr.openjdk.java.net/~briangoetz/amber/constables.html