RFR: 8336856: Optimize String Concat [v4]

[Shaojin Wen]

On Tue, 23 Jul 2024 10:19:47 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 two additional commits since the last revision:
> 
>  - reduce change & refactor
>  - fix TRUSTED not work

The bytecode-spinning-based implementation is working, except for one test (java/lang/String/concat/WithSecurityManager.java) which fails. I have verified that this test fails in the generate branch, and the reason needs to be analyzed.


Now:
1. Keep the implementation of unaryConcat and simpleConcat, which is the same as before in simple scenarios.
2. When the number of parameters is less than HIGH_ARITY_THRESHOLD, use the acceptInlineCopy implementation based on bytecode-spinning, and when the number of parameters is greater than HIGH_ARITY_THRESHOLD, use the original generate path
3. Access private methods through the TRUSTED Mode of MethodHandles.Lookup.IMPL_LOOKUP.

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

PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2245083720