[8u-dev] RFR (S): JDK-8194653: Deadlock involving FileSystems.getDefault and System.loadLibrary call
Alan.Bateman at oracle.com
Wed Apr 24 11:26:54 UTC 2019
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.
More information about the core-libs-dev