On Mon, 12 Aug 2024 16:52:53 GMT, Shaojin Wen <d...@openjdk.org> wrote:
>> src/java.base/share/classes/java/lang/StringConcatHelper.java line 83:
>>
>>> 81:
>>> 82: @ForceInline
>>> 83: private final String concat(char value) {
>>
>> These mostly help avoid a bit of class spinning on startup, right? I think
>> it's fine to add these now, but we should perhaps consider ways to
>> pre-generate concat shapes more deliberately (e.g. using
>> `GenerateJLIClassesHelper/-Plugin` to pre-spin concat classes when jlinking
>> an image) rather than manually stamping out code here. If small arity
>> concats benefit in throughput tests from a subtly different code shape then
>> that should be reflected in the code generator.
>
> The current implementation generates length and coder methods, which slows
> down the startup. The built-in concat1 is to improve the startup speed. 1
> parameter is a very common scenario. The current implementation does not need
> to add more classes. It is a lightweight implementation, so I keep it. In
> addition, I also need to learn how GenerateJLIClassesHelper works.
Right, what you have is OK here. I'll think a bit about a follow-up to
integrate with the plugin to support arbitrary concat class pre-generation in
jlink. This is something I had hoped to get done in the previous
implementation, but I ran into a few road blocks there and then had to work on
other things. With this implementation doing pre-generation will likely be way
more straightforward.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20273#discussion_r1714135667
