> 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 with a new target base due to a merge 
or a rebase. The pull request now contains 32 commits:

 - Merge remote-tracking branch 'upstream/master' into 
optim_concat_factory_202407
 - typo
 - change comments
 - minor refactor
 - minor refactor
 - reduce change
 - copyright
 - reduce change
 - refactor based on 8335182
 - use Float.toString & Double.toString
 - ... and 22 more: https://git.openjdk.org/jdk/compare/05d88de0...6faecfd7

-------------

Changes: https://git.openjdk.org/jdk/pull/20273/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20273&range=10
  Stats: 278 lines in 2 files changed: 265 ins; 1 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/20273.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20273/head:pull/20273

PR: https://git.openjdk.org/jdk/pull/20273

Reply via email to