RFR: 8335182: Consolidate and streamline String concat code shapes
Claes Redestad
redestad at openjdk.org
Thu Jun 27 17:31:44 UTC 2024
On Thu, 27 Jun 2024 16:05:09 GMT, Chen Liang <liach at openjdk.org> wrote:
>> This PR attains a speed-up on some microbenchmarks by simplifying how we build up the MH combinator tree shape
>> (only use prependers with prefix, always add a suffix to the newArray combinator), then simplifying/inlining some of the code in the helper functions.
>>
>> Many simple concatenation expressions stay performance neutral, while the win comes from enabling C2 to better optimize more complex shapes (concat13String, concatMix4String, concatConst6String see relatively large improvements):
>>
>>
>> Name Cnt Base Error Test Error Unit Change
>> StringConcat.concat13String 50 66.380 ± 0.189 53.017 ± 0.241 ns/op 1.25x (p = 0.000*)
>> StringConcat.concat4String 50 13.620 ± 0.053 12.382 ± 0.089 ns/op 1.10x (p = 0.000*)
>> StringConcat.concat6String 50 17.168 ± 0.070 16.046 ± 0.064 ns/op 1.07x (p = 0.000*)
>> StringConcat.concatConst2String 50 9.820 ± 0.081 8.158 ± 0.041 ns/op 1.20x (p = 0.000*)
>> StringConcat.concatConst4String 50 14.938 ± 0.124 12.800 ± 0.049 ns/op 1.17x (p = 0.000*)
>> StringConcat.concatConst6Object 50 56.115 ± 0.288 54.046 ± 0.214 ns/op 1.04x (p = 0.000*)
>> StringConcat.concatConst6String 50 19.032 ± 0.073 16.213 ± 0.093 ns/op 1.17x (p = 0.000*)
>> StringConcat.concatConstBoolByte 50 8.486 ± 0.066 8.556 ± 0.050 ns/op 0.99x (p = 0.004*)
>> StringConcat.concatConstInt 50 8.942 ± 0.052 7.677 ± 0.029 ns/op 1.16x (p = 0.000*)
>> StringConcat.concatConstIntConstInt 50 12.883 ± 0.070 12.431 ± 0.070 ns/op 1.04x (p = 0.000*)
>> StringConcat.concatConstString 50 7.523 ± 0.050 7.486 ± 0.044 ns/op 1.00x (p = 0.058 )
>> StringConcat.concatConstStringConstInt 50 11.961 ± 0.032 11.699 ± 0.049 ns/op 1.02x (p = 0.000*)
>> StringConcat.concatEmptyConstInt 50 7.778 ± 0.038 7.723 ± 0.037 ns/op 1.01x (p = 0.000*)
>> StringConcat.concatEmptyConstString 50 3.506 ± 0.026 3.505 ± 0.015 ns/op 1.00x (p = 0.930 )
>> StringConcat.concatEmptyLeft 50 3.573 ± 0.075 3.518 ± 0.057 ns/op 1.02x (p = 0.044 )
>> StringConcat.concatEmptyRight 50 3.713 ± 0.049 3.622 ± 0.053 ns/op 1.02x (p = 0.000*)
>> StringConcat.concatMethodConstString 50 7.418 ± 0.030 7.478 ± 0.066 ns/op 0.99x (p...
>
> src/java.base/share/classes/java/lang/StringConcatHelper.java line 157:
>
>> 155: }
>> 156: index -= prefix.length();
>> 157: prefix.getBytes(buf, index, String.LATIN1);
>
> Since we are now passing in a lot of empty prefix, I wonder how this call is elided; is there some specific JIT intrinsic? The java code has no shortcut for `length == 0`.
Remember that the prefixes are all constants and bound into the MH at each call site, so one view is that this PR is mostly about tickling the code into something that just-so happens to be easier for the JIT to swallow
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19927#discussion_r1657513167
More information about the security-dev
mailing list