RFR: 8336856: Optimize String Concat [v19]

[Claes Redestad]

On Sun, 28 Jul 2024 13:58:05 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 one additional commit since the last revision:
> 
>   cache generate MethodHandle

Making the recipe part of the key in such a cache is probably not what we want since it means that we'll produce different classes for `"foo" + bar` and `"baz" + bar` and only return the cached handle on exact recipe match. This will do little to reduce class generation pressure. We would need a slightly different code generation strategy for this to fly: cache only on method handle, cache the constructor to the generated class which takes the array of constants. This is a larger commitment which is why I suggested we do it as a follow-up.

To make the class unloadable (which we need here and now for this PR) it might be sufficient to replace `SET_OF_STRONG` with the empty set, `Set.of()`. The hidden class will be strongly reachable from callsites. I'm working on a test to verify this, I might have something ready and send you a PR soon.

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

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