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. ------------- Commit messages: - Include some callsites in StringLatin1/UTF16, rename to copyBytes to disambiguate from generic utility methods, tune microbenchmark - 8301958: Avoid overhead of Arrays.copyOfRange in String Changes: https://git.openjdk.org/jdk/pull/12453/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12453&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301958 Stats: 36 lines in 4 files changed: 14 ins; 2 del; 20 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
