On Thu, 25 Jul 2024 08:58:14 GMT, Shaojin Wen <d...@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
