RFR: 8259947: (fs) Optimize UnixPath.encode implementation

Aleksey Shipilev shade at openjdk.java.net
Tue Jan 19 10:49:51 UTC 2021


On Tue, 19 Jan 2021 00:35:51 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.

Changes requested by shade (Reviewer).

test/micro/org/openjdk/bench/java/io/FileToPath.java line 53:

> 51:         bh.consume(new File(normalFile).toPath());
> 52:         bh.consume(new File(trailingSlash).toPath());
> 53:         bh.consume(new File(root).toPath());

No singular test for `new File(root)`, but here it is in the `mix` anyway? What would probably be not comparable.

test/micro/org/openjdk/bench/java/io/FileToPath.java line 46:

> 44:     public String root = "/";
> 45:     public String trailingSlash = "/test/dir/file/name.txt/";
> 46:     public String notNormalizedFile = "/test/dir/file//name.txt";

Can be `private`, I think. As long as those are not `static final`...

-------------

PR: https://git.openjdk.java.net/jdk/pull/2135


More information about the core-libs-dev mailing list