Possible VM deadlock due to FileSystems.getDefault and System.loadLibrary interplay
vitalyd at gmail.com
Thu Jan 4 12:05:05 UTC 2018
On Thu, Jan 4, 2018 at 3:03 AM, Alan Bateman <Alan.Bateman at oracle.com>
> 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 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?
More information about the core-libs-dev