> 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: Update StringLatin1.trim for consistency ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12453/files - new: https://git.openjdk.org/jdk/pull/12453/files/5b637e09..a5e494bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12453&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12453&range=01-02 Stats: 9 lines in 2 files changed: 0 ins; 0 del; 9 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
