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.
NetBeans IDE Dev (Build 200704041800, C/C++ Pack 20070404) 1.6.0_01-ea; Java HotSpot(TM) Client VM 1.6.0_01-ea-b03 Linux version 2.6.18-1.2239_1.fc5.cubbi_suspend2 running on i386 en_US (nb); UTF-8 using NBI insatller with all components. There are many paths how org.netbeans.modules.uml.project.UMLProject instances are held in memory even when project is closed. Here are some of them - Static reference from org.netbeans.modules.uml.ui.support.applicationmanager.DiagramKeyboardAccessProvider.kbAccessProvider (from class org.netbeans.modules.uml.ui.support.applicationmanager.DiagramKeyboardAccessProvider) : --> org.netbeans.modules.uml.ui.support.applicationmanager.DiagramKeyboardAccessProvider@0x6dfd0138 (16 bytes) (field drawingAreaCtrl:) --> org.netbeans.modules.uml.ui.swing.drawingarea.ADDrawingAreaControl@0x6fe97a78 (660 bytes) (field m_Namespace:) --> org.netbeans.modules.uml.core.metamodel.structure.Project@0x6d9a4418 (106 bytes) (field mSourceRoots:) --> org.netbeans.modules.uml.project.AssociatedSourceProvider@0x6da3af10 (20 bytes) (field umlProj:) --> org.netbeans.modules.uml.project.UMLProject@0x6d9a44c0 (44 bytes) Static reference from java.awt.Window.allWindows (from class java.awt.Window) : --> java.util.Vector@0x6ca11d48 (24 bytes) (field elementData:) --> [Ljava.lang.Object;@0x70538660 (328 bytes) (Element 13 of [Ljava.lang.Object;@0x70538660:) --> org.netbeans.modules.uml.ui.addins.associateDialog.AssociateDlgGUI@0x6e3f5ed0 (493 bytes) (field m_Project:) --> org.netbeans.modules.uml.core.metamodel.structure.Project@0x6d9a4418 (106 bytes) (field mSourceRoots:) --> org.netbeans.modules.uml.project.AssociatedSourceProvider@0x6da3af10 (20 bytes) (field umlProj:) --> org.netbeans.modules.uml.project.UMLProject@0x6d9a44c0 (44 bytes) Static reference from org.netbeans.modules.uml.ui.support.DispatchHelper.m_DrawingAreaDispatcher (from class org.netbeans.modules.uml.ui.support.DispatchHelper) : --> org.netbeans.modules.uml.ui.controls.drawingarea.DrawingAreaEventDispatcherImpl@0x6d1f20f0 (73 bytes) (field m_DrawingAreaEventManager:) --> org.netbeans.modules.uml.core.eventframework.EventManager@0x6d1f3bd8 (20 bytes) (field m_listeners:) --> java.util.Vector@0x6d1f5eb8 (24 bytes) (field elementData:) --> [Ljava.lang.Object;@0x6f157cc0 (88 bytes) (Element 2 of [Ljava.lang.Object;@0x6f157cc0:) --> org.netbeans.modules.uml.project.ui.nodes.UMLDiagramsRootNode@0x6dae2da0 (118 bytes) (field helper:) --> org.netbeans.modules.uml.project.UMLProjectHelper@0x6d9a44a0 (28 bytes) (field mNBProject:) --> org.netbeans.modules.uml.project.UMLProject@0x6d9a44c0 (44 bytes) Static reference from org.netbeans.modules.uml.ui.controls.newdialog.NewDialogUtilities.m_Elements (from class org.netbeans.modules.uml.ui.controls.newdialog.NewDialogUtilities) : --> java.util.Vector@0x6da99fb8 (24 bytes) (field elementData:) --> [Ljava.lang.Object;@0x6da9b4d0 (48 bytes) (Element 0 of [Ljava.lang.Object;@0x6da9b4d0:) --> org.netbeans.modules.uml.core.metamodel.structure.Project@0x6f053778 (106 bytes) (field mSourceRoots:) --> org.netbeans.modules.uml.project.AssociatedSourceProvider@0x6f081ec8 (20 bytes) (field umlProj:) --> org.netbeans.modules.uml.project.UMLProject@0x6f081dc0 (44 bytes)
moving to P3 according to http://performance.netbeans.org/processes/bug_priority_guidelines.html specifically "# small memory leak of a functionality which is not used often" on the basis that : 1. the leak is small (quick look shows that the numbers listed add up to something less than about 2K) 2. the functionality (ie. operation of closing of an UML project) isn't supposed to be used often (supposedly up to several times per session; it may even happen that user doesn't close the projects s/he working with for a series of sessions )
this issue may affect tests automation, performance problems start after 20-30 test in testbug (and it was almost impossible to execute more then 120 test even with closing previously used projects), but most likely it's only a part of problem, may be some memory usage of xtest affects tests too.
Those "listed objects" are not a list of all leaked objects. It is a "root path" - objects on the path to the GC root and their size is in fact irrelevant. The leak is much bigger than that (everything retained by the UMLProject instance). I don't have the numbers, but Radim will certainly add them and raise the priority accordingly.
Sorry, I was too short. What I did: opened UML project, played a bit with two class diagrams created from scratch so these contain only a few items. Then I closed these diagrams and project and did couple of other editor and project related actions to avoid noise caused by some LRU references. What is the problem: The project cannot be released from memory. Project obviously hold many other items: mEval (L) : org.netbeans.spi.project.support.ant.PropertyUtils$SequentialPropertyEvaluator@0x7c9a2368 (24 bytes) mGenFilesHelper (L) : org.netbeans.spi.project.support.ant.GeneratedFilesHelper@0x7c9a2358 (16 bytes) mHelper (L) : org.netbeans.modules.uml.project.UMLProjectHelper@0x7c9a2320 (28 bytes) mImportSupport (L) : org.netbeans.modules.uml.project.ui.customizer.UMLImportsUiSupport@0x7c9a2380 (24 bytes) mListener (L) : org.netbeans.modules.uml.project.UMLProjectMetadataListener@0x7c9a2398 (12 bytes) mLookup (L) : org.openide.util.lookup.SimpleLookup@0x7c9a2310 (12 bytes) mRefHelper (L) : org.netbeans.spi.project.support.ant.ReferenceHelper@0x7c9a2340 (24 bytes) obj (L) : org.netbeans.modules.uml.project.UMLProjectDataObject@0x7c9a6e60 (62 bytes) uiProperties (L) : org.netbeans.modules.uml.project.ui.customizer.UMLProjectProperties@0x7c9a6e20 (60 bytes) through UMLProjectHelper you can get easily to org.netbeans.modules.uml.core.metamodel.structure.Project holding dom4j tree. It means (>7500 with my toy size sample) instances of org.dom4j.dom.DOMElement, their listeners leads to hundreds of kB not counting DOMAttributes, QNames and String for the identifiers yet ('DCE.36444423-1683-7AC3-98AA-570C15AC5862' takes 24+88 bytes in memory). Another interesting path is through ADProduct -> EventDispatchController --> ElementChangeEventDispatcher --> EventManager holding several hundred iteresting items like org.netbeans.modules.uml.drawingarea.DiagramTopComponent$LocalUMLModelElementNode org.netbeans.modules.uml.project.ui.nodes.UMLModelElementNode. It means again hundreds of instances in simple project eachof them retaining associated data structures too. Now back in reference chain: Both instances of ADDrawingAreaControl is held although they should not be. These keep DiagramTopComponent so even if you work with the same project there will be leaking instances of TopComponent. To lvv: I hope you see now that your 1. is not correct. Please use your judgement to set the priority. Also I do not agree with 2. This is not a single purpose product and has a variety of usages. Switching between projects (of the same or different type) is one of them. It is fair to expect that session can last for days and context will be updated several times during this time.
Thank you for the additional info. I see your point. It looks like you possibly hit the "gold" here and fixing this memory leak problem is going to result in a significant improvement. In this light it is definitely a P2, a "fat" one. (close to being P1 base on "performance-biased" treatment of the criterias, yet i'd like to avoid possibility of destabilizing M9 now, as the fix will possibly touch a lot of sensitive places) We'll definitely work on it, hope soon, ie. in early phase of 6.0 as performance fixes at later, higher resistance stages, aren't always welcome.
i took a quick look into the list of all reference chains from rootsets (excluding weak refs) and there is a large amount of refs from the Netbeans platform/infrastructure code, non-UML related. I tried the same experiment without any UML specifics, ie. with J2SEProject (ie. close the project, click memory indicator to initiate the gc, and dump the heap after that) - the J2SEProject also didn't get collected. You'll find the listing of the reference chains attached. Do you have bug(s) filed for this already? If not, should i file it myself?
Created attachment 41222 [details] static refernces to J2SEProject
Just a thought about effective and reasonable usage of priorities. Filing this bug did you see the references from outside of the UML code? The references could hardly be missed. Yet the bug was still originally filed as a P1 - i just don't understand how it was supposed to be fixed in a P1 mode/timeframe.
Good catch. This one (NbSheet) usually slips because properties window is closed by default in slim IDE (just Java support). Note that there are several more of this kind - #100752, #100753, #100755. Good news is that these are just last used projects / editors where the references are flushed if the context is updated again (new project is opened / node selected / editor created. It means it is not cumulating if you repeat the activity. Checking in src/org/openide/explorer/propertysheet/PropertySheet.java; /shared/data/ccvs/repository/openide/explorer/src/org/openide/explorer/propertysheet/PropertySheet.java,v <-- PropertySheet.java new revision: 1.15; previous revision: 1.14 done Checking in test/unit/src/org/openide/explorer/propertysheet/PropertiesFlushTest.java; /shared/data/ccvs/repository/openide/explorer/test/unit/src/org/openide/explorer/propertysheet/PropertiesFlushTest.java,v <-- PropertiesFlushTest.java new revision: 1.3; previous revision: 1.2 done
fixed.
assume this has already been verified.