Using NIO FS in java.util.zip.ZipFile

[Konstantin Nisht]

Hello everyone,

In JetBrains, we are working on the improvement of interaction with WSL.
Due to a bug in Windows, certain interaction with WSL filesystem is
unreasonably slow:
https://youtrack.jetbrains.com/issue/IJPL-149160/java.util.zip.ZipFile-is-slow-on-WSL
The reproducer uses plain Java IO API, so the problem is not in our
codebase. We think that it is possible to fix it by using Java NIO with a
custom `java.nio.file.spi.FileSystemProvider` (which we also need for other
purposes), but there is no way of currently doing it for
`java.util.zip.ZipFile`.

We have an idea of a fix: one can observe that `ZipFile` uses
`java.io.RandomAccessFile` internally, which has a similar interface to
`SeekableByteChannel`. We attempted to patch JDK in order for `ZipFile` to
use `FileChannel` (https://github.com/JetBrains/JetBrainsRuntime/pull/413),
and noticed the following issues:
1. On Windows, `RandomAccessFile` opens a file without `FILE_SHARE_DELETE`
mode. `FileChannel`, on the contrary, does open a file in this mode, which
results in subtle differences reflected in the test `TestZipError.java`.
See more in
https://github.com/JetBrains/JetBrainsRuntime/pull/413#issuecomment-2218299753
. I suspect that it is possible to fix by the use of
`ExtendedOpenOption.NOSHARE_DELETE`, but the patch would be more
complicated.
2. A more serious issue, `FileChannel` performs reading and writing using
direct buffers. It breaks an (implicit?) contract that by default JVM does
not allocate memory-mapped files, as reflected by the test
`LimitDirectMemory.java`.

Currently, we are going to apply the proposed patch to our builds, but we
would like to hear your thoughts on whether it is possible to include it in
the upstream of OpenJDK.

Best regards,
Konstantin Nisht,
JetBrains.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20240712/fc6005ee/attachment.htm>