<i18n dev> RFR: 8278642: Refactor java.util.Formatter

[Claes Redestad]

On Wed, 15 Dec 2021 20:09:22 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> A few refactorings to how `java.util.Formatter` sets up `FormatString`s, aligning the implementation with changes explored by the TemplatedStrings JEP and ever so slightly improving performance:
>> 
>> - turn `Flags` into an `int` (fewer allocations in the complex case)
>> - remove some superfluous varargs: `checkBadFlags(Flags.PARENTHESES, ...` -> `checkBadFlags(Flags.Parentheses | ...` - again less allocations in the complex cases since these varargs arrays were being allocated. Also improves error messages since all bad flags will be listed in the exception message.
>> - make `FormatSpecifier` and `FixedString` static, reducing size of these objects slightly.
>> 
>> Baseline: 
>> 
>> Benchmark                                                           Mode  Cnt     Score     Error   Units
>> StringFormat.complexFormat                                          avgt   25  8977.043 ± 246.810   ns/op
>> StringFormat.complexFormat:·gc.alloc.rate.norm                      avgt   25  2144.170 ±   0.012    B/op
>> StringFormat.stringFormat                                           avgt   25   252.109 ±   2.732   ns/op
>> StringFormat.stringFormat:·gc.alloc.rate.norm                       avgt   25   256.019 ±   0.001    B/op
>> StringFormat.stringIntFormat                                        avgt   25   576.423 ±   4.596   ns/op
>> StringFormat.stringIntFormat:·gc.alloc.rate.norm                    avgt   25   432.034 ±   0.002    B/op
>> StringFormat.widthStringFormat                                      avgt   25   999.835 ±  20.127   ns/op
>> StringFormat.widthStringFormat:·gc.alloc.rate.norm                  avgt   25   525.509 ±  14.742    B/op
>> StringFormat.widthStringIntFormat                                   avgt   25  1332.163 ±  30.901   ns/op
>> StringFormat.widthStringIntFormat:·gc.alloc.rate.norm               avgt   25   720.715 ±   8.798    B/op
>> 
>> 
>> Patch:
>> 
>> Benchmark                                                           Mode  Cnt     Score    Error   Units
>> StringFormat.complexFormat                                          avgt   25  8840.089 ± 51.222   ns/op
>> StringFormat.complexFormat:·gc.alloc.rate.norm                      avgt   25  1736.151 ±  0.009    B/op
>> StringFormat.stringFormat                                           avgt   25   247.310 ±  2.091   ns/op
>> StringFormat.stringFormat:·gc.alloc.rate.norm                       avgt   25   248.018 ±  0.001    B/op
>> StringFormat.stringIntFormat                                        avgt   25   565.487 ±  6.572   ns/op
>> StringFormat.stringIntFormat:·gc.alloc.rate.norm                    avgt   25   408.032 ±  0.002    B
>> StringFormat.widthStringFormat                                      avgt   25   970.015 ± 32.915   ns/op
>> StringFormat.widthStringFormat:·gc.alloc.rate.norm                  avgt   25   449.991 ± 25.716    B/op
>> StringFormat.widthStringIntFormat                                   avgt   25  1284.572 ± 28.829   ns/op
>> StringFormat.widthStringIntFormat:·gc.alloc.rate.norm               avgt   25   636.872 ±  7.331    B/op
>
> Looks good to me.  Not a big improvement, but as much as it gets used.  ��

Thanks for reviews, @RogerRiggs and @naotoj ! 

Yes, the speed-up is a bit underwhelming. I had to dial back some more promising optimizations I was exploring (#6792) after realizing they'd be breaking semantics in case of an illegal format string. These are the cleanups and pile-on optimizations I could salvage from that experiment, along with some harmonization with changes @JimLaskey is doing for TemplatedStrings.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6821