RFR: 8336856: Optimize String Concat [v15]

[Claes Redestad]

On Thu, 25 Jul 2024 08:58:14 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> The current implementation of StringConcat is to mix the coder and length into a long. This operation will have some overhead for int/long/boolean types. We can separate the calculation of the coder from the calculation of the length, which can improve the performance in the scenario of concat int/long/boolean.
>> 
>> This idea comes from the suggestion of @l4es in the discussion of PR https://github.com/openjdk/jdk/pull/20253#issuecomment-2240412866
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add benchmark

test/micro/org/openjdk/bench/java/lang/StringConcatGenerate.java line 47:

> 45: @Measurement(iterations = 5, time = 1000, timeUnit = TimeUnit.MILLISECONDS)
> 46: @Fork(value = 3, jvmArgsAppend = "-Djava.lang.invoke.StringConcat.highArityThreshold=0")
> 47: public class StringConcatGenerate extends StringConcat {

Adding a subclass with an overridden `@Fork` to pass a different `jvmArgsAppend` is a reasonable trick, but could be moved to a nested class within `StringConcat` to keep it in the same context. I'm not sure if this micro brings a persistent added value, though: for experimentation we can just run `StringConcat` with different `-Djava.lang.invoke.StringConcat.highArityThreshold` settings, while for continuous regression testing we're more interested in validating the default settings. Supplying the new `main` method doesn't add anything here, either, since a standalone execution wouldn't pick up the `jvmArgsAppend` value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1691205621