> This adds a local, specialized `copyBytes` method to `String` that avoids > certain redundant range checks and clamping that JIT has issues removing > fully. > > This has a small but statistically significant effect on `String` > microbenchmarks, eg.: > > Baseline > > Benchmark (size) Mode Cnt > Score Error Units > StringConstructor.newStringFromArray 7 avgt 15 > 16.817 ± 0.369 ns/op > StringConstructor.newStringFromArrayWithCharset 7 avgt 15 > 16.866 ± 0.449 ns/op > StringConstructor.newStringFromArrayWithCharsetName 7 avgt 15 > 22.198 ± 0.396 ns/op > > > Patch: > > Benchmark (size) Mode Cnt > Score Error Units > StringConstructor.newStringFromArray 7 avgt 15 > 15.477 ± 0.342 ns/op > StringConstructor.newStringFromArrayWithCharset 7 avgt 15 > 15.557 ± 0.352 ns/op > StringConstructor.newStringFromArrayWithCharsetName 7 avgt 15 > 21.272 ± 0.398 ns/op > > > Care has to be taken to ensure preconditions have been checked when using > `checkBytes`. In the case of `String(AbstractStringBuilder)` there's a > possible pre-existing issue where the constructor might either throw an > exception or truncate the buffer if the builder byte array and length is not > in agreement (theoretically possible if you clear/remove and call > `trimToSize()` concurrently). Adding an explicit check here seem to be the > right thing to do regardless of this RFE.
Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: fix StringUTF16.trim bug, rename locals to reduce confusion ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12453/files - new: https://git.openjdk.org/jdk/pull/12453/files/2d1f8e37..5b637e09 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12453&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12453&range=00-01 Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/12453.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12453/head:pull/12453 PR: https://git.openjdk.org/jdk/pull/12453