RFR: 8301958: Avoid Arrays.copyOfRange overhead in java.lang.String
Claes Redestad
redestad at openjdk.org
Tue Feb 7 13:46:28 UTC 2023
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
More information about the core-libs-dev
mailing list