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

2018-01-04 Thread 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 of DefaultFileSystemHolder, which in turn leads to Runtime.loadLibrar

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

2018-01-04 Thread Vitaly Davidovich
On Thu, Jan 4, 2018 at 3: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 of >> DefaultFileSystemHolder, which in turn le

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

2018-01-04 Thread 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 of DefaultFileSystemHolder, which in turn leads to Runtime.loadLibrary0 which needs to lock the Runtime instance

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

2018-01-03 Thread David Holmes
On 4/01/2018 12:26 PM, Vitaly Davidovich wrote: On Wed, Jan 3, 2018 at 8:36 PM David Holmes > wrote: On 4/01/2018 3:13 AM, Vitaly Davidovich wrote: > On Wed, Jan 3, 2018 at 12:00 PM, Alan Bateman mailto:alan.bate...@oracle.com>> > wrote: >

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

2018-01-03 Thread Vitaly Davidovich
On Wed, Jan 3, 2018 at 8:36 PM David Holmes wrote: > On 4/01/2018 3:13 AM, Vitaly Davidovich wrote: > > On Wed, Jan 3, 2018 at 12:00 PM, Alan Bateman > > wrote: > > > >> The stack trace looks like JDK 8 or older. The initialization has > changed > >> quite a bit in JDK 9+ and would be interestin

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

2018-01-03 Thread David Holmes
On 4/01/2018 3:13 AM, Vitaly Davidovich wrote: On Wed, Jan 3, 2018 at 12:00 PM, Alan Bateman wrote: The stack trace looks like JDK 8 or older. The initialization has changed quite a bit in JDK 9+ and would be interesting to see if you can duplicate it there. Yes - it's 8u152 as I mentioned i

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

2018-01-03 Thread Vitaly Davidovich
On Wed, Jan 3, 2018 at 12:00 PM, Alan Bateman wrote: > The stack trace looks like JDK 8 or older. The initialization has changed > quite a bit in JDK 9+ and would be interesting to see if you can duplicate > it there. > Yes - it's 8u152 as I mentioned in the follow-up email (sorry, should've ment

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

2018-01-03 Thread Alan Bateman
The stack trace looks like JDK 8 or older. The initialization has changed quite a bit in JDK 9+ and would be interesting to see if you can duplicate it there. -Alan On 03/01/2018 16:56, Vitaly Davidovich wrote: Hi all, Consider the following stacktraces of the main app thread and a backgroun

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

2018-01-03 Thread Vitaly Davidovich
Sorry, I should've mentioned that this is 8u152. On Wed, Jan 3, 2018 at 11:56 AM, Vitaly Davidovich wrote: > Hi all, > > Consider the following stacktraces of the main app thread and a background > thread: > > "main" #1 prio=5 os_prio=0 tid=0x01bfd000 nid=0x1958 waiting for > monitor ent

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

2018-01-03 Thread Vitaly Davidovich
Hi all, Consider the following stacktraces of the main app thread and a background thread: "main" #1 prio=5 os_prio=0 tid=0x01bfd000 nid=0x1958 waiting for monitor entry [0x2b98ceba3000] java.lang.Thread.State: BLOCKED (on object monitor) at java.lang.Runtime.load