Possible VM deadlock due to FileSystems.getDefault and System.loadLibrary interplay (original) (raw)

mandy chung mandy.chung at oracle.com
Thu Jan 4 22:52:45 UTC 2018

On 1/4/18 12:03 AM, Alan Bateman wrote:

On 04/01/2018 01:35, David Holmes wrote:

You're not missing anything. It's a class initialization related "deadlock". Thread A has called FileSystems.getDefault() which is doing of DefaultFileSystemHolder, which in turn leads to Runtime.loadLibrary0 which needs to lock the Runtime instance. Thread B is already doing a loadLibrary and holds the Runtime lock, the loadLibrary code then needs to do FileSystems.getDefault() which has to load and initialize DefaultFileSystemHolder, but that initialization is already in progress so internally the thread does a wait(). So Thread B is waiting for Thread A to finish initialization, but holds the monitor lock that Thread A needs to finish the initialization. Deadlock. AFAICS this will still be possible in 9/10/11 Startup and initialization has changed quite a bit since JDK 8. In JDK 9 the file system is initialized early (long before main). However, it changes again in JDK 10 due to ongoing work to makes things lazy and improve startup time. Separately, FilePermission and the JarFile support have been re-written so it should be loaded before any user code executes. So I think needs to be studied again, I agree with your other mail to create a bug to track that.

This is indeed a deadlock.   I created https://bugs.openjdk.java.net/browse/JDK-8194653 to track this.

Mandy

More information about the core-libs-dev mailing list