On Fri, 2 Aug 2024 00:59:06 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: > > Fix performance regression caused by args.erase() The following test will see the performance regression git checkout d573c297219115976ad03f70fbd7777aedc3d4b8 make test TEST="micro:java.lang.StringConcat.concatConst6Object" MICRO="VM_OPTIONS=-Djava.lang.invoke.StringConcat.highArityThreshold=0" git checkout e2b30b3f5f74ba8881e3674f3e0beef12883b138 make test TEST="micro:java.lang.StringConcat.concatConst6Object" MICRO="VM_OPTIONS=-Djava.lang.invoke.StringConcat.highArityThreshold=0" # d573c29 Benchmark (intValue) Mode Cnt Score Error Units StringConcat.concatConst6Object 4711 avgt 15 74.717 ? 8.146 ns/op # e2b30b3 Benchmark (intValue) Mode Cnt Score Error Units StringConcat.concatConst6Object 4711 avgt 15 51.573 ? 0.385 ns/op ------------- PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2264308978
