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