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.
[dev-200109260100; Sun JDK 1.3.1; MDI] I've performed a few steps of the newly prepared "Smoke test": Create new project - open Project Manager (menu Project -> Project Manager) - push "New..." button - push OK in "Create New Project" dialog Mount file systems - mount Local Directory (nb_all/) - unmount - mount Archive (nb_all/core/netbeans/lib/core.jar) - unmout ... after this step, the IDE becomes very busy, a lot of disk-thrashing, slower UI response... - mount Local Directory (nb_all/nbbuild) - mount Archive (nb_all/openide/netbeans/lib/openide.jar) ... the last operation takes several minutes. First it looks like a dead-lock (thread-dump 1), later the IDE comes back to life, but everything takes unbearably long (workspace switching, menu popping, tree selections, ...). See the other two thread-dumps for details. The Windows Task Manager shows that the processor is at 100% and most of the time is consumed by the bash.exe process (yes, I started NetBeans from the cygwin's bash).
Created attachment 2721 [details] thread-dump 1
Created attachment 2722 [details] thread-dump 2
Created attachment 2723 [details] thread-dump 3
Reassigned to David Strupl. Please investigate : "All packages processor" daemon
Sorry.
The second and third thread-dump signals a possible room for optimization: PackageChildren.updatePackages creates DataObject to pass it to DataFilter we could skip this step if the DataFilter == DataFilter.ALL which is likely this case...
Increasing priority -> P1. I can reproduce it reliably now. It looks like ObjectBrowser is involved somehow: New steps to reproduce: 1. Start with a clean userdir 2. Switch to the Browsing workspace 3. Switch back to Editing 4. In the Explorer, mount nb_all as a local filesystem ... now the disk starts thrashing. The thrashing doesn't occur when step 2 is skipped... 5. Expand the filesystem node 6. Unmount the filesystem -- the thrashing doesn't stop!!! 7. Repeat steps 4..6 with core.jar, nb_all/nbbuild, openide.jar, etc. ... sooner or later you should experience a noticable slowdown in the UI responsiveness, the processor is at 100%, the IDE becomes almost unusable.
The problems are IMHO in file Packages between lines 350 and 410. Investigating ...
Please note this issue which affects filtering too http://www.netbeans.org/issues/show_bug.cgi?id=13585
If the filesystem is removed the processing is interrupted and should quickly stop. Packages.java rev. 1.10
Created attachment 2763 [details] thread-dump 4
I agree that stopping the package processing after the filesystem is unmounted is a desirable performance optimization, but it doesn't solve the primary cause of the problem, I'm afraid. Reopening, because I'm able to reproduce the same behavior (IDE almost dead, processor at 100%) with dev-20010928. If I mount several filesystems with a large number of files (like nb_all), after a while the UI becomes less and less responsive and never recovers from this state, it only gets worse (thread-dump 4).
I'll check it.
First of all the object browsers asks three times for list of all packages: createNode: org.netbeans.modules.objectbrowser.PackagesFilter$InnerFilter@7ab89d java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:993) at org.netbeans.core.PackageChildren.createNode(PackageChildren.java:72) at org.netbeans.core.NbPlaces.packages(NbPlaces.java:87) at org.netbeans.modules.objectbrowser.ClassBrowserHierarchyTranslator.getPackagesHierarchy(ClassBrowserHierarchyTranslator.java:234) at org.netbeans.modules.objectbrowser.ClassBrowserHierarchyTranslator.translate(ClassBrowserHierarchyTranslator.java:159) at org.netbeans.modules.objectbrowser.ExplorerBean$3.run(ExplorerBean.java:433) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:154) at java.awt.EventQueue.dispatchEvent(EventQueue.java:337) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:131) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:98) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:85) update: 8 f: org.netbeans.modules.objectbrowser.PackagesFilter$InnerFilter@7ab89d == org.openide.loaders.DataFilterAll@5b03a1 createNode: org.netbeans.modules.objectbrowser.PackagesFilter$InnerFilter@7ab89d java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:993) at org.netbeans.core.PackageChildren.createNode(PackageChildren.java:72) at org.netbeans.core.NbPlaces.packages(NbPlaces.java:87) at org.netbeans.modules.objectbrowser.ClassBrowserHierarchyTranslator.getPackagesHierarchy(ClassBrowserHierarchyTranslator.java:234) at org.netbeans.modules.objectbrowser.ClassBrowserHierarchyTranslator.translate(ClassBrowserHierarchyTranslator.java:159) at org.netbeans.modules.objectbrowser.ExplorerBean$3.run(ExplorerBean.java:433) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:154) at java.awt.EventQueue.dispatchEvent(EventQueue.java:337) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:131) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:98) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:85) createNode: org.netbeans.modules.objectbrowser.PackagesFilter$InnerFilter@7ab89d java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:993) at org.netbeans.core.PackageChildren.createNode(PackageChildren.java:72) at org.netbeans.core.NbPlaces.packages(NbPlaces.java:87) at org.netbeans.modules.objectbrowser.ClassBrowserHierarchyTranslator.getPackagesHierarchy(ClassBrowserHierarchyTranslator.java:234) at org.netbeans.modules.objectbrowser.ClassBrowserHierarchyTranslator.translate(ClassBrowserHierarchyTranslator.java:159) at org.netbeans.modules.objectbrowser.ExplorerBean$3.run(ExplorerBean.java:433) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:154) at java.awt.EventQueue.dispatchEvent(EventQueue.java:337) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:131) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:98) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:85) createNode: org.netbeans.modules.objectbrowser.PackagesFilter$InnerFilter@7ab89d java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:993) at org.netbeans.core.PackageChildren.createNode(PackageChildren.java:72) at org.netbeans.core.NbPlaces.packages(NbPlaces.java:87) at org.netbeans.modules.objectbrowser.ClassBrowserHierarchyTranslator.getPackagesHierarchy(ClassBrowserHierarchyTranslator.java:234) at org.netbeans.modules.objectbrowser.ClassBrowserHierarchyTranslator.translate(ClassBrowserHierarchyTranslator.java:159) at org.netbeans.modules.objectbrowser.ExplorerBean$3.run(ExplorerBean.java:433) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:154) at java.awt.EventQueue.dispatchEvent(EventQueue.java:337) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:131) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:98) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:85) this has to be reduced and/or also the provided filter should be different if no filtering is necessary. The object browser asks for its own filter (which probably always returns true anyway) but there is an optimilization in core for DataFilter.ALL, objectbrowser, please if no filtering is enabled, use DataFilter.ALL, please. Instead of org.netbeans.modules.objectbrowser.PackagesFilter$InnerFilter@7ab89d Use org.openide.loaders.DataFilterAll@5b03a1
Object browser optimized to use DataFilter.ALL
After reinvestigating problem with Yarda, reassigning
I am not able to find anything wrong. At least I have added a bunch of log messages to Packages.java please run with -Dorg.netbeans.core.Packages=-5 and reopen if you find something wrong.
*** Issue 12616 has been marked as a duplicate of this issue. ***
Created attachment 2788 [details] Log file (-Dorg.netbeans.core.Packages=-5) with thread-dump
No, it doesn't work. I can reliably reproduce it with build 200110020100. I'm attaching the requested log file with another thread-dump. Hope it helps. One thing I realized: some of the local filesystems I'm mounting are children of larger local filesystems mounted previously. Could this matter?
Packages rev. 1.13
Created attachment 2789 [details] A patch to test whether behaviour improved
Created attachment 2793 [details] Yet another log with a thread-dump
Still reproducible, even with the patch. Maybe it took longer to reproduce this time, but I'm not sure. New log and thread-dump attached.
I tried to find out why the AWT blocks for a while. Obviously something is occupaing AWT thread, but what. First observation that with huge filesystems there can be thousands children of the packages () node. There is nothing to do with it. It will be slow. I watched the log and when it prints updating children, I tried stacktraces. AWT thread was occupried, but the problem seems to be in ExplorerBean. I guess that a lot of code there could be run out of AWT thread thus improving user experience. Why following code runs in SwingUtilities? */ private void refreshNodes () { if (translator != null) { setSubFilter (translator.getFilter (rootNodes, filter, this)); SwingUtilities.invokeLater (new Runnable () { public void run () { Node nnn = translator.translate (rootNodes, filter, subFilter); //S ystem.out.println ("Explorer bean - setRoot " + nnn); // NOI18N //Thread.dumpStack (); explorerManager.setRootContext (nnn); try { explorerManager.setSelectedNodes (new Node[] {}); } catch (PropertyVetoException e) { } } }); } else
Again classhierarchy translator is called from AWT event thread. I do not know why, in my opinion this is not needed. My guess is that this invokes back the PackagesChildren.update... in "All Packages" Thread. Please investigate if there is a way how to stop this behaviour... "AWT-EventQueue-0" prio=7 tid=0xac00808 nid=0x658 waiting on monitor [0x1182f000 ..0x1182fdbc] at java.lang.Object.wait(Native Method) at org.openide.util.Mutex$QueueCell.sleep(Mutex.java:1105) at org.openide.util.Mutex.enter(Mutex.java:460) at org.openide.util.Mutex.postRequest(Mutex.java:813) at org.openide.util.Mutex.postWriteRequest(Mutex.java:353) at org.openide.nodes.Children$Keys.applyKeys (Children.java:1721) at org.openide.nodes.Children$Keys.setKeys(Children.java:1680) at org.openide.loaders.DataObjectFilter.setKeysHelper (DataObjectFilter.j ava:364) at org.openide.loaders.DataObjectFilter.refreshAll (DataObjectFilter.java :396) at org.openide.loaders.DataObjectFilter.setDataFolder (DataObjectFilter.j ava:259) at org.netbeans.modules.objectbrowser.ClassBrowserHierarchyTranslator.ge tHierarchyForPackage(ClassBrowserHierarchyTranslator.java:303) at org.netbeans.modules.objectbrowser.ClassBrowserHierarchyTranslator.tr anslate(ClassBrowserHierarchyTranslator.java:168) at org.netbeans.modules.objectbrowser.ExplorerBean.refreshNodes(Explorer Bean.java:431) at org.netbeans.modules.objectbrowser.ExplorerBean.dataItemAvailable(Exp lorerBean.java:543) at javax.infobus.DefaultController.fireItemAvailable (DefaultController.j ava:90) at javax.infobus.InfoBus.fireItemAvailable(InfoBus.java:995) at org.netbeans.modules.objectbrowser.ExplorerBean$1.propertyChange(Expl orerBean.java:141) at java.beans.PropertyChangeSupport.firePropertyChange (PropertyChangeSup port.java:152) at org.openide.explorer.ExplorerManager.setSelectedNodes (ExplorerManager .java:204) at org.openide.explorer.view.ListView.selectionChanged (ListView.java:358 ) at org.openide.explorer.view.ListView$Listener.valueChanged (ListView.jav a:673) at javax.swing.DefaultListSelectionModel.fireValueChanged (DefaultListSel ectionModel.java:170) at javax.swing.DefaultListSelectionModel.fireValueChanged (DefaultListSel ectionModel.java:150) at javax.swing.DefaultListSelectionModel.fireValueChanged (DefaultListSel ectionModel.java:197) at javax.swing.DefaultListSelectionModel.changeSelection (DefaultListSele ctionModel.java:359) at javax.swing.DefaultListSelectionModel.changeSelection (DefaultListSele ctionModel.java:368) at javax.swing.DefaultListSelectionModel.setSelectionInterval (DefaultLis tSelectionModel.java:392) at javax.swing.JList.setSelectionInterval(JList.java:1209) at javax.swing.plaf.basic.BasicListUI$MouseInputHandler.mousePressed(Bas icListUI.java:795) at java.awt.AWTEventMulticaster.mousePressed (AWTEventMulticaster.java:22 1) at java.awt.AWTEventMulticaster.mousePressed (AWTEventMulticaster.java:22 0) at java.awt.AWTEventMulticaster.mousePressed (AWTEventMulticaster.java:22 0) at java.awt.AWTEventMulticaster.mousePressed (AWTEventMulticaster.java:22 0) at java.awt.Component.processMouseEvent(Component.java:3712) at java.awt.Component.processEvent(Component.java:3544) at java.awt.Container.processEvent(Container.java:1164) at java.awt.Component.dispatchEventImpl(Component.java:2593) at java.awt.Container.dispatchEventImpl(Container.java:1213) at java.awt.Component.dispatchEvent(Component.java:2497) at javax.swing.plaf.basic.BasicInternalFrameUI$GlassPaneDispatcher.retar getMouseEvent(BasicInternalFrameUI.java:1221) at javax.swing.plaf.basic.BasicInternalFrameUI$GlassPaneDispatcher.forwa rdMouseEvent(BasicInternalFrameUI.java:1148) at javax.swing.plaf.basic.BasicInternalFrameUI$GlassPaneDispatcher.mouse Pressed(BasicInternalFrameUI.java:1087) at java.awt.Component.processMouseEvent(Component.java:3712) at java.awt.Component.processEvent(Component.java:3544) at java.awt.Container.processEvent(Container.java:1164) at java.awt.Component.dispatchEventImpl(Component.java:2593) at java.awt.Container.dispatchEventImpl(Container.java:1213) at java.awt.Component.dispatchEvent(Component.java:2497) at java.awt.LightweightDispatcher.retargetMouseEvent (Container.java:2451 ) at java.awt.LightweightDispatcher.processMouseEvent (Container.java:2210) at java.awt.LightweightDispatcher.dispatchEvent (Container.java:2125) at java.awt.Container.dispatchEventImpl(Container.java:1200) at java.awt.Window.dispatchEventImpl(Window.java:914) at java.awt.Component.dispatchEvent(Component.java:2497) at java.awt.EventQueue.dispatchEvent(EventQueue.java:339) at java.awt.EventDispatchThread.pumpOneEventForHierarchy (EventDispatchTh read.java:131) at java.awt.EventDispatchThread.pumpEventsForHierarchy (EventDispatchThread.java:98) at java.awt.EventDispatchThread.pumpEvents (EventDispatchThread.java:93) at java.awt.EventDispatchThread.run (EventDispatchThread.java:85) "Signal Dispatcher" daemon prio=10 tid=0x994118 nid=0x178 waiting on monitor [0..0] "Finalizer" daemon prio=9 tid=0x990218 nid=0x6d0 waiting on monitor [0xb03f000..0xb03fdbc] at java.lang.Object.wait(Native Method) at java.lang.ref.ReferenceQueue.remove (ReferenceQueue.java:108) at java.lang.ref.ReferenceQueue.remove (ReferenceQueue.java:123) at java.lang.ref.Finalizer$FinalizerThread.run (Finalizer.java:162) "Reference Handler" daemon prio=10 tid=0x98eda8 nid=0x6d4 waiting on monitor [0x af3f000..0xaf3fdbc] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at java.lang.ref.Reference$ReferenceHandler.run (Reference.java:110) "main" prio=5 tid=0x934580 nid=0x694 waiting on monitor [0..0x12d178] "VM Thread" prio=5 tid=0xab400a8 nid=0x588 runnable "VM Periodic Task Thread" prio=10 tid=0x992e78 nid=0x63c waiting on monitor "Suspend Checker Thread" prio=10 tid=0x993790 nid=0x578 runnable [org.netbeans.core.Packages] updating finished [org.netbeans.core.Packages] updating children: org.netbeans.core.PackageChildre n@28c064
How the keyword can be missing in this case?
I guess in the time of mounting/umounting of a filesystem, the ObjectBrowser is not visible. Why it needs to recount the list of packages when nobody asks? If I start the IDE on the editing workspace, I can mount and umount the filesystems without ever touching Packages class, without single refresh (because OB window is now created lazily enough). If I once switch to OB workspace, packages are refreshed for the first time (It takes some time), when I switch back to the editing and mount/umount something, packages get refreshed again. WHY? I do not see the results, I do not use them, but the OB window is active and Packages are actively tracking changes in repository. Why not just to mark the information as invalid and recompute it on request? Or am I missing something?
All code of OB has not been under care at least 1 1/2 year and is out of date (bug has probably existed for long time). I try to find acceptable workaround for the bug.
Some problems probably can be in Node's finalization, if I mount some large FS and unmount it quickly, everything works ok, if I unmount it after longer time (more nodes are created), IDE goes to unstable state, I often get java.lang.OutOfMemoryError (I have -Xmx96m set)
I test this bug under NB3.2.1 (Build98), the bug is present too.
I have merged performance improvements in Packages.java and PackageChildren.java into QBE branch. The rest has to be done on the objectbrowser side, I think. Likely it is related to garbage collection. There are probably two options: 1. when object browser received remove/add Notify than resent the explorerManager.setRootContext (...) to some different node than packages. 2. forbid the garbage collection of subnodes in packages ().getChildren ().getNodes () somehow or do not ask for new values if not needed (not visible)
The garbage collection could probably be prevented in NodeListModel. David, will try to investigate it.
I tested garbage collection in ChildrenArray.finalize() I got children finalize Templates/Mount children finalize org.openide.actions.NewTemplateAction$RootChildren@615a1f children finalize Templates children finalize org.openide.actions.NewTemplateAction$RootChildren@674592 children finalize Templates children finalize Templates/Mount children finalize org.openide.actions.NewTemplateAction$RootChildren@778b7d children finalize Templates children finalize org.openide.actions.NewTemplateAction$RootChildren@2f7016 children finalize Templates/Mount children finalize org.openide.actions.NewTemplateAction$RootChildren@6a906f
lowered prio to P2 because of the improvements we made so far
Resolved as much as possible. Now as design.
Target milestone -> 3.3.1.
Now, we did maximum for this bug. The bug is an architecture problem.
Obsolete. Closing.