RFR: 8260710: Inline and simplify String*::{coder, value, isLatin1} methods

[Ioi Lam]

On Tue, 9 Feb 2021 13:06:36 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Since Compact Strings implementation, there are simple methods in String and StringBuilders: `coder()`, `value()`, `isLatin1()`. They are mostly there to capture `COMPACT_STRINGS` flag that would fold to "false" when compact strings are disabled with `-XX:-CompactStrings`.
>> 
>> This was to guarantee the same performance when Compact String are unimplemented and/or have surprising performance behaviors. Quite some time had passed since JDK 9 release, and we can consider simplifying these. For example, ignoring `COMPACT_STRINGS` and inlining the methods simplifies the code. Some new code added to `String` after JDK 9 already has these methods inlined, checking `coder` directly.
>> 
>> The major drawback is that supplying `-XX:-CompactStrings` would have to go through the same `coder == UTF16` paths the "normal" Compact Strings are going. It would not be folded to the most optimal form by the optimizer, because `coder` field value is generally opaque to optimizers.
>> 
>> On the flip side, there is an advantage on paths that do not have optimizer ready (yet), for example at startup. Hello World startup improves for about 0.3 msec (or ~1.3%). The improvement is quite probably more visible on larger workloads, i.e. large application servers. (In fact, this is where I spotted this opportunity: OpenLiberty startup profiles).
>> 
>> Interpreter-only "Hello World":
>> 
>>  Performance counter stats for 'taskset -c 13 build/baseline/bin/java -Xms128m -Xmx128m -Xint Hello' (5000 runs):
>> 
>>              23.40 msec task-clock                #    0.933 CPUs utilized            ( +-  0.01% )
>>         86,133,190      cycles                    #    3.680 GHz                      ( +-  0.01% )
>>         79,854,588      instructions              #    0.93  insn per cycle           ( +-  0.00% )
>> 
>>         0.02507105 +- 0.00000343 seconds time elapsed  ( +-  0.01% )
>> 
>>  Performance counter stats for 'taskset -c 13 build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m -Xint Hello' (5000 runs):
>> 
>>              23.07 msec task-clock                #    0.935 CPUs utilized            ( +-  0.01% )
>>         84,877,118      cycles                    #    3.679 GHz                      ( +-  0.01% )
>>         79,231,598      instructions              #    0.93  insn per cycle           ( +-  0.00% )
>> 
>>         0.02466467 +- 0.00000382 seconds time elapsed  ( +-  0.02% )
>> 
>> 
>> OpenLiberty startup:
>> 
>>  Before: 2.296, 2.281, 2.291 (seconds)
>>  After:  2.254, 2.267, 2.272 (seconds)
>> 
>> Additional tests:
>>  - [x] Linux `tier1` default (passes)
>>  - [x] Linux `tier1` `-XX:-CompactStrings`
>
> Looks good to me.

> It would be useful to drive a discussion of removing fallback provided
> by COMPACT_STRINGS? entirely.
> It was retained initially as a hedge against bugs in the new implementation.
> It adds complexity to the implementation and can hide implementation bugs.

Isn't COMPACT_STRING inherently slower if you are processing predominantly Chinese/Japanese/Korean text?

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

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