Possible VM deadlock due to FileSystems.getDefault and System.loadLibrary interplay

[mandy chung]

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 <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 
>> 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