On Sun, 28 Jul 2024 13:58:05 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 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
