RFR: 8336831: Optimize StringConcatHelper.simpleConcat [v5]
Shaojin Wen
duke at openjdk.org
Fri Jul 19 22:52:32 UTC 2024
On Fri, 19 Jul 2024 22:28:40 GMT, Claes Redestad <redestad at openjdk.org> wrote:
>> Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:
>>
>> - Update src/java.base/share/classes/java/lang/String.java
>>
>> Co-authored-by: Chen Liang <liach at openjdk.org>
>> - add comments
>
> FWIW one of the ideas when implementing `StringConcatHelper.simpleConcat` was that by using the primitives used by the `StringConcatFactory` as straightforwardly as possible the method acts as a documentation-of-sorts or guide to understand how the `SCF` expression trees are built up. It's not perfect, though. Concatenation of a `String` + constant would be handled differently for one. So perhaps the value as a guide is not high.
>
> I'm also experimenting with replacing the MH-based strategy with spinning hidden, shareable classes instead. In that case we might actually be better off getting rid of the `long indexCoder` hacks and generate code more similar to the `doConcat` you've come up with here. The main benefit of combining `coder` and `index/length` into a single `long` was to reduce the MH combinator overheads, but if we're spinning code with access to optimized primitives then that isn't really needed.
@cl4es Is it your idea to provide some String + primitive doConcat method and use it in StringConcatFactory to generate MH?
doConcat(String,boolean)
doConcat(String,char)
doConcat(String,int)
doConcat(String,long)
doConcat(boolean, String)
doConcat(char, String)
doConcat(int, String)
doConcat(long, String)
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20253#issuecomment-2240494811
More information about the core-libs-dev
mailing list