RFR: 8336856: Optimize String Concat

[Claes Redestad]

On Sun, 21 Jul 2024 12:25:36 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

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