RFR: 8148937: (str) Adapt StringJoiner for Compact Strings

[Claes Redestad]

On Thu, 18 Feb 2021 20:14:12 GMT, Сергей Цыпанов <github.com+10835776+stsypanov at openjdk.org> wrote:

>> Some of these changes conflict with #2334, which suggest removing the `coder` and `isLatin1` methods from `String`. 
>> 
>> As a more general point I think it would be good to explore options that does not increase leakage of the implementation detail that `Strings` are latin1- or utf16-encoded outside of java.lang.
>
> Hi @cl4es,
>> Some of these changes conflict with #2334, which suggest removing the `coder` and `isLatin1` methods from `String`.
> 
> I've checked out Aleksey's branch and applied my changes onto it, the only thing that I changed to make it work is replacing
> public boolean isLatin1(String str) {
>     return str.isLatin1();
> }
> with
> public boolean isLatin1(String str) {
>     return str.coder == String.LATIN1;
> }
> The rest of the code was left intact. `jdk:tier1` is OK after the change.
>> As a more general point I think it would be good to explore options that does not increase leakage of the implementation detail that `Strings` are latin1- or utf16-encoded outside of java.lang.
> 
> Apart from `JavaLangAccess` the only thing that comes to my mind is reflection, but it will destroy all the improvement. Otherwise I cannot figure out any other way to access somehow package-private latin/non-latin functionality of `j.l.String` in `java.util` package. I wonder, whether I'm missing any other opportunities?

A less intrusive alternative would be to use a `StringBuilder`, see changes in this branch: https://github.com/openjdk/jdk/compare/master...cl4es:stringjoin_improvement?expand=1 (I adapted your StringJoinerBenchmark to work with the ascii-only build constraint)

This underperforms compared to your patch since StringBuilder.toString needs to do a copy, but improves over the baseline:
Benchmark                                                            (count)  (length)  (mode)  Mode  Cnt      Score      Error   Units
StringJoinerBenchmark.stringJoiner                                       100        64   latin  avgt    5   5420.701 ± 1433.485   ns/op
StringJoinerBenchmark.stringJoiner:·gc.alloc.rate.norm                   100        64   latin  avgt    5  20640.428 ±    0.130    B/op
Patch:
Benchmark                                                            (count)  (length)  (mode)  Mode  Cnt      Score      Error   Units
StringJoinerBenchmark.stringJoiner                                       100        64   latin  avgt    5   4271.401 ±  677.560   ns/op
StringJoinerBenchmark.stringJoiner:·gc.alloc.rate.norm                   100        64   latin  avgt    5  14136.294 ±    0.095    B/op

The comparative benefit is that we'd avoid punching more holes into String implementation details for now. Not ruling that out indefinitely, but I think it needs a stronger motivation than to improve StringJoiner alone.

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

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