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

[Alan Bateman]

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.

-Alan