<div dir="ltr"><div><div>> Is there a brief summary on what the performance is?<br></div>It takes 1 minute 20 seconds to open a 12 kb zip file located on the Linux side of WSL from Windows. The same file can be opened in 0.02 seconds if located on Windows.<br> This problem is in the implementation of 9P by Microsoft, but it is quite difficult to workaround it, especially when we have clients that use pure <a href="http://java.io">java.io</a>. <br><br><span class="gmail-im">> </span>The motive for these prototypes is virtual threads.<br></div>Could you clarify how FileChannel helps here?<br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 12, 2024 at 6:11 PM Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com">Alan.Bateman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 12/07/2024 16:06, Konstantin Nisht wrote:<br>
> Hello everyone,<br>
><br>
> In JetBrains, we are working on the improvement of interaction with <br>
> WSL. Due to a bug in Windows, certain interaction with WSL filesystem <br>
> is unreasonably slow: <br>
> <a href="https://youtrack.jetbrains.com/issue/IJPL-149160/java.util.zip.ZipFile-is-slow-on-WSL" rel="noreferrer" target="_blank">https://youtrack.jetbrains.com/issue/IJPL-149160/java.util.zip.ZipFile-is-slow-on-WSL</a><br>
<br>
Is there a brief summary on what the performance is?<br>
<br>
<br>
> The reproducer uses plain Java IO API, so the problem is not in our <br>
> codebase. We think that it is possible to fix it by using Java NIO <br>
> with a custom `java.nio.file.spi.FileSystemProvider` (which we also <br>
> need for other purposes), but there is no way of currently doing it <br>
> for `java.util.zip.ZipFile`.<br>
><br>
> We have an idea of a fix: one can observe that `ZipFile` uses <br>
> `java.io.RandomAccessFile` internally, which has a similar interface <br>
> to `SeekableByteChannel`. We attempted to patch JDK in order for <br>
> `ZipFile` to use `FileChannel` <br>
> (<a href="https://github.com/JetBrains/JetBrainsRuntime/pull/413" rel="noreferrer" target="_blank">https://github.com/JetBrains/JetBrainsRuntime/pull/413</a>), and noticed <br>
> the following issues:<br>
> 1. On Windows, `RandomAccessFile` opens a file without <br>
> `FILE_SHARE_DELETE` mode. `FileChannel`, on the contrary, does open a <br>
> file in this mode, which results in subtle differences reflected in <br>
> the test `TestZipError.java`. See more in <br>
> <a href="https://github.com/JetBrains/JetBrainsRuntime/pull/413#issuecomment-2218299753" rel="noreferrer" target="_blank">https://github.com/JetBrains/JetBrainsRuntime/pull/413#issuecomment-2218299753</a> <br>
> . I suspect that it is possible to fix by the use of <br>
> `ExtendedOpenOption.NOSHARE_DELETE`, but the patch would be more <br>
> complicated.<br>
<br>
As it happens, Brian Burkhalter and I have been noodling on a <br>
re-implementation of <a href="http://java.io" rel="noreferrer" target="_blank">java.io</a>, including RandomFileAccess that sits on <br>
FileChannel. It sets up the FileChannel to not be interruptible as that <br>
<a href="http://java.io" rel="noreferrer" target="_blank">java.io</a> is not interruptible. We also have prototype changes to ZipFile <br>
to cleanup how OPEN_DELETE works. The motive for these prototypes is <br>
virtual threads. The main hurdle is startup performance, we still have <br>
some regressions due to some additional class loading + code executed <br>
that need to be worked on. The prototype we have handles <br>
FILE_SHARE_DELETE so there are no observable behavioral differences.<br>
<br>
<br>
> 2. A more serious issue, `FileChannel` performs reading and writing <br>
> using direct buffers. It breaks an (implicit?) contract that by <br>
> default JVM does not allocate memory-mapped files, as reflected by the <br>
> test `LimitDirectMemory.java`.<br>
There is nothing to prohibit JDK classes from using direct buffers or do <br>
memory mapping, there are several examples of this already.<br>
<br>
-Alan<br>
</blockquote></div>