[8u-dev] RFR (S): JDK-8194653: Deadlock involving FileSystems.getDefault and System.loadLibrary call

[Alan Bateman]

On 23/04/2019 22:53, Sciampacone, Ryan wrote:
> Agreed on the changes since JDK9.
>
> This specific problem doesn't exist in jdk/jdk because even in a (for my example, linux) product image, although FileSystems isn't touched, sun.nio.fs.UnixNativeDispatcher gets initialized as part of startup - this clears up the native library load (nio) collision that could occur through that class.  This is the case we see customers experiencing.  Preloading FileSystems.getDefault() in jdk8 is a mostly inert and friendly (not reaching into the bowels, letting the platform pick the right class) way of getting that problem out of the way.
>
> You can see the corresponding stack traces here that highlight the issue: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-January/050819.html
>
I realize you are running the issue with JDK 8 but I think we do need to 
investigate the main line a bit more too. You are correct that the file 
system is initialized early in JDK 9 but this isn't the case for JDK 10 
and newer due to further work to reduce startup time. The stack traces 
in the bug report look like they may have been taken with an exploded 
build or with --patch-module, just two of several cases where it might 
be initialized early. I think it will be harder to demonstrate an issue 
with JDK 10, esp. if there are JAR files on the class path as any access 
to JAR files will trigger the file system to be initialized.

-Alan