On Sun, 21 Jul 2024 12:25:36 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 This reverts startup optimizations which are important for the overall performance of the current MH-based implementation. I did not suggest splitting apart length and coder in the context of this current implementation, but that in a non-MH-based implementation that combination trick makes little sense. I am trying to find time to work out the kinks of a bytecode-spinning solution and would appreciate it if we leave the venerable `StringConcatFactory` alone for the time being - at least until after JVMLS (Aug 5-7). (I noticed in some tests that splitting apart like this seem to only affect M1/aarch64, not x64, suggesting some JIT compiler deficiency on aarch64. Perhaps that would be a useful side track to explore.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20273#issuecomment-2241602473
