RFR: 8259947: (fs) Optimize UnixPath.encode implementation [v3]
Aleksey Shipilev
shade at openjdk.java.net
Wed Jan 20 14:08:57 UTC 2021
On Tue, 19 Jan 2021 12:26:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:
>> This patch improves `UnixPath.encode` by reusing `JLA.getBytesNoRepl` (which has fast-paths for common encoding) and avoiding a `toCharArray` call on the input by refactoring the `normalizeNativePath` code to operate on `String`. This might have a cost on files on Mac that need additional native normalization.
>>
>> This removes another `ThreadLocal` and a source of `SoftReference`s. Together with the UTF-8 fast-path my UTF-8 encoded file system see substantial speed-ups in a trivial `new File(str).toPath()` microbenchmark.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>
> Move JLA to top, add imports
test/micro/org/openjdk/bench/java/io/FileOpen.java line 103:
> 101: @Warmup(time=2, iterations=5)
> 102: @Measurement(time=3, iterations=5)
> 103: @Fork(value=2, jvmArgs="-Xmx1g")
I thought this can be inherited from the enclosing benchmark.
test/micro/org/openjdk/bench/java/io/FileOpen.java line 104:
> 102: @Measurement(time=3, iterations=5)
> 103: @Fork(value=2, jvmArgs="-Xmx1g")
> 104: public static class ToPath {
Do we really have to nest this test? It seems to gain nothing per se: the annotations and fields are still pretty much duplicated.
-------------
PR: https://git.openjdk.java.net/jdk/pull/2135
More information about the core-libs-dev
mailing list