On Fri, 19 Jul 2024 22:49:41 GMT, Shaojin Wen <d...@openjdk.org> wrote:
>> 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) @wenshao We note that we only need to update coder if we are concating a String; primitives are always Latin1. So coder can be one of the 3 cases: 1. Latin1, when all constant Strings are Latin1 and all arguments are primitive (even though floating point needs conversion to strings) 2. UTF16, when any constant String is UTF16 3. On-demand detection, when all constant strings are Latin1 but some arguments are Strings. Using these clues, we might be able to generate more efficient bytecode, which is also free from MethodHandle tree's trouble of inlining when the size is too huge. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20253#issuecomment-2240914855
