Possible VM deadlock due to FileSystems.getDefault and System.loadLibrary interplay
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
>> Thread A has called FileSystems.getDefault() which is doing <clinit>
>> 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
>> 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.
More information about the core-libs-dev