On Tue, 23 Jul 2024 10:19:47 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 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
