On Thu, Jan 4, 2018 at 3:03 AM, Alan Bateman <[email protected]> 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 >
