On Thu, 18 Feb 2021 20:14:12 GMT, Сергей Цыпанов
<github.com+10835776+stsypa...@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
