RFR - JDK-8210550 - Applying String::align and String::indent at Compile Time

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Jim Laskey" <james.laskey at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "compiler-dev" <compiler-dev at openjdk.java.net>
> Envoyé: Mardi 11 Septembre 2018 17:16:43
> Objet: Re: RFR -  JDK-8210550 - Applying String::align and String::indent at Compile Time

> Remi,
> 
> After further discussion we’ve decided close this review and move this task to
> JEP 303.
> 
> Follow up,
> 
> 1) If you have a have a constantRSL.align() or constantRSL.indent(n) you will
> end up with two strings in the heap after compilation (pre-call and post-call.)

yes, maybe it means that when we will add the lazy resolution of the constant pool for bootstrap arguments, we should have a way to get the value of a constant pool index without caching it, so only the post-call result will be in the heap

> 2) Agree this is not a strong argument unless you are looping on the string and
> you haven't hit the compile threshold (rare-ish thing.)

VMs routinely have a threshold per loop and do on stack replacement.

And you still have the constant dynamic option, which is not zero cost but you pay the cost of the call only once.

I wonder if the best is not to use constant dynamic and have a jlink plugin and/or CDS that does the constant folding, so you play the cost once if the library/application is deliver as a jar or zero if you pre-link your application.

> 
> Note: this optimization was only done in preview mode.
> 
> Cheers,
> 
> — Jim

Rémi

> 
>> On Sep 10, 2018, at 6:45 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>> Hi Jim,
>> There is a big drawback of doing that in the compiler, if String::align or
>> String::indent has a bug, users will have to recompile all their codes which is
>> not something we are used to in Java.
>> 
>> Moreover, i'm not convinced by the arguments cited in the bug description
>> 1) minimum space is used to represent the string in the class file and
>> 2) zero runtime cost occurs.
>> 
>> For (1) it depends! String::indent can add more spaces so the original text may
>> may smaller than the result of a call to indent.
>> For (2) there is no real performance penalty once the JIT (even c1) kicks in.
>> Also, if we don't want to wait the JIT, using constant dynamic is another
>> option.
>> 
>> There is is another issue, why String::strip is constant folded and not
>> String::trim ?
>> Java 12 have not being used yet, so we do not know which method is popular and
>> which is not, so who decide which method should be constant folded or not.
>> 
>> And in term of implementation,
>> - the javadoc should clearly reflect which methods is constant folded, by an
>> annotation by example
>> - it will help all languages that consumes the JDK API (instead of each compiler
>> maintaining its own set)
>> 
>> regards,
>> Rémi
>> 
>> ----- Mail original -----
>>> De: "Jim Laskey" <james.laskey at oracle.com>
>>> À: "compiler-dev" <compiler-dev at openjdk.java.net>
>>> Envoyé: Lundi 10 Septembre 2018 18:52:45
>>> Objet: RFR -  JDK-8210550 - Applying String::align and String::indent at Compile
>>> Time
>> 
>>> Please review the following webrev.  This feature is a tied implementation of
>>> Raw String Literals and supporting String methods.
>>> 
>>> Cheers,
>>> 
>>> — Jim
>>> 
>>> webrev: http://cr.openjdk.java.net/~jlaskey/8210550/webrev/index.html
> >> jbs: https://bugs.openjdk.java.net/browse/JDK-8210550