This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
After starting up NetBeans this morning & opening an HTML5 project, NetBeans hung again. Since NetBeans itself was unusable, I opened VisualVM (attached is an application snapshot). And again it showed the "W32 File Monitor" thread as the culprit. I don't understand why the JNA-based Windows Notifier is still being used, when a JDK-supported alternative is available with the NIO2-based Notifier. I don't know if the fault is with NTFS, Windows, JNA, or the Notifier implementation itself, but obviously the current WindowsNotifier doesn't scale well and/or deadlocks/hangs in certain scenarios. In my opinion, replacing the default Notifier with the NIO2 implementation is a must. At the very least, NetBeans should provide some option (e.g. in netbeans.conf) to set the Notifier implementation that should be used (native or NIO2). Product Version: NetBeans IDE Dev (Build 201509130002) Updates: Updates available Java: 1.8.0_60; Java HotSpot(TM) 64-Bit Server VM 25.60-b23 Runtime: Java(TM) SE Runtime Environment 1.8.0_60-b27 System: Windows 7 version 6.1 running on amd64; Cp1252; en_US (nb)
Created attachment 156538 [details] Java VisualVM snapshot of NetBeans
For the record, I'm talking about these: https://hg.netbeans.org/main-silver/file/b0638b8eca84/masterfs.nio2/src/org/netbeans/modules/masterfs/watcher/nio2/NioNotifier.java https://hg.netbeans.org/main-silver/file/b0638b8eca84/masterfs.windows/src/org/netbeans/modules/masterfs/watcher/windows/WindowsNotifier.java Also note that the NIO2 implementation is 4 times smaller than the Windows implementation...
The problem has nothing to do with "W32 File Monitor" thread. This thread is native code, which consumes just a fraction of CPU. The main problem blocked AWT in explorer: "AWT-EventQueue-0" #21 prio=6 os_prio=0 tid=0x000000001800c800 nid=0x3fc in Object.wait() [0x000000001d7da000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at org.netbeans.modules.openide.util.DefaultMutexImplementation$QueueCell.sleep(DefaultMutexImplementation.java:1229) - locked <0x00000000cc0a4c10> (a org.netbeans.modules.openide.util.DefaultMutexImplementation$QueueCell) at org.netbeans.modules.openide.util.DefaultMutexImplementation.enterImpl(DefaultMutexImplementation.java:498) at org.netbeans.modules.openide.util.DefaultMutexImplementation.enter(DefaultMutexImplementation.java:405) at org.netbeans.modules.openide.util.DefaultMutexImplementation.readEnter(DefaultMutexImplementation.java:388) at org.netbeans.modules.openide.util.DefaultMutexImplementation.readAccess(DefaultMutexImplementation.java:249) at org.netbeans.modules.openide.util.DefaultMutexImplementation$1R.run(DefaultMutexImplementation.java:1078) at org.openide.nodes.Children$ProjectManagerDeadlockDetector.execute(Children.java:1938) at org.netbeans.modules.openide.util.DefaultMutexImplementation.doWrapperAccess(DefaultMutexImplementation.java:1099) at org.netbeans.modules.openide.util.DefaultMutexImplementation.readAccess(DefaultMutexImplementation.java:245) at org.openide.util.Mutex.readAccess(Mutex.java:218) at org.openide.explorer.view.TreeView$ExplorerTree$GuardedActions.<init>(TreeView.java:2196) at org.openide.explorer.view.TreeView$ExplorerTree.paint(TreeView.java:1848)
Created attachment 156543 [details] Thread dump excerpt Deadlock between Active Reference Queue daemon and NodeFactorySupport. Write access is used in EntrySupportDefault.finalizedChildrenArray.
*** This bug has been marked as a duplicate of bug 253732 ***
> ... replacing the default Notifier with the NIO2 implementation ... Although it is not related to the reported bug, it is a good point. I've created separate issue 255757. Thank you for reporting.