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