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

[Vitaly Davidovich]

On Thu, Jan 4, 2018 at 3:03 AM, Alan Bateman <Alan.Bateman at oracle.com>
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.

Alan, David - thanks for your comments.

Alan - I'm assuming someone from Oracle will file a bug report for this?

>
>
> -Alan
>