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.

Bug 101462 - Leaking UML objects
Summary: Leaking UML objects
Status: RESOLVED WONTFIX
Alias: None
Product: uml
Classification: Unclassified
Component: Project (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: issues@uml
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2007-04-17 21:40 UTC by _ rkubacki
Modified: 2009-05-25 21:06 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description _ rkubacki 2007-04-17 21:40:53 UTC
NetBeans IDE Dev (Build 070417)
1.6.0_01; Java HotSpot(TM) Client VM 1.6.0_01-b06
Linux version 2.6.18-1.2239_1.fc5.cubbi_suspend2 running on i386
en_US (nb); UTF-8

I did some editing of class diagrams in UML project and when the project is
closed there are still many objects belonging to UML support held in memory.


org.netbeans.modules.uml.core.support.umlutils.PropertyDefinition (5901
instances, 596001 bytes) 

These are held through 
org.netbeans.modules.uml.ui.controls.editcontrol.EditControlImpl (21 instances
of not disposed windows) like here:

Static reference from java.awt.Window.allWindows (from class java.awt.Window) :
--> java.util.Vector@0x7b64e518 (24 bytes) (field elementData:)
--> [Ljava.lang.Object;@0x7d87d868 (168 bytes) (Element 12 of
[Ljava.lang.Object;@0x7d87d868:)
--> javax.swing.JDialog@0x7d7c8d30 (363 bytes) (field rootPane:)
--> javax.swing.JRootPane@0x7d7c9170 (353 bytes) (field contentPane:)
--> org.netbeans.modules.uml.ui.controls.editcontrol.EditControlImpl@0x7d7c92d8
(433 bytes) (field m_Translator:)
--> org.netbeans.modules.uml.ui.controls.editcontrol.TranslatorImpl@0x7d7ca0b8
(59 bytes) (field m_TextFields:)
--> java.util.Vector@0x7d7ca768 (24 bytes) (field elementData:)
--> [Ljava.lang.Object;@0x7d7ccc58 (48 bytes) (Element 3 of
[Ljava.lang.Object;@0x7d7ccc58:)
--> org.netbeans.modules.uml.ui.controls.editcontrol.EditControlField@0x7d7cd198
(104 bytes) (field m_PropertyDefinition:)
--> org.netbeans.modules.uml.core.support.umlutils.PropertyDefinition@0x7d7cd7f0
(109 bytes) (field m_VecSubDefs:)
--> java.util.Vector@0x7d7ce048 (24 bytes) (field elementData:)
--> [Ljava.lang.Object;@0x7d7ceaa0 (48 bytes) (Element 0 of
[Ljava.lang.Object;@0x7d7ceaa0:)
--> org.netbeans.modules.uml.core.support.umlutils.PropertyDefinition@0x7d7cf310
(109 bytes) (field m_VecSubDefs:)
--> java.util.Vector@0x7d7cf830 (24 bytes) (field elementData:)
--> [Ljava.lang.Object;@0x7d7cfaf8 (48 bytes) (Element 2 of
[Ljava.lang.Object;@0x7d7cfaf8:)
--> org.netbeans.modules.uml.core.support.umlutils.PropertyDefinition@0x7d7cff60
(109 bytes) 

or from 

Static reference from
org.netbeans.modules.uml.propertysupport.DefinitionPropertyBuilder.mBuilderInstance
(from class org.netbeans.modules.uml.propertysupport.DefinitionPropertyBuilder) :
-->
org.netbeans.modules.uml.propertysupport.DefinitionPropertyBuilder@0x7cc7d348
(24 bytes) (field mDefFactory:)
-->
org.netbeans.modules.uml.core.support.umlutils.PropertyDefinitionFactory@0x7cc7d288
(40 bytes) (field m_DefinitionMap:)
--> java.util.Hashtable@0x7cc84808 (40 bytes) (field table:)
--> [Ljava.util.Hashtable$Entry;@0x7cf1d328 (1540 bytes) (Element 264 of
[Ljava.util.Hashtable$Entry;@0x7cf1d328:)
--> java.util.Hashtable$Entry@0x7cde4f50 (24 bytes) (field value:)
--> org.netbeans.modules.uml.core.support.umlutils.PropertyDefinition@0x7cde6778
(109 bytes) (field m_VecSubDefs:)
--> java.util.Vector@0x7ce2aec0 (24 bytes) (field elementData:)
--> [Ljava.lang.Object;@0x7ce70ff8 (88 bytes) (Element 9 of
[Ljava.lang.Object;@0x7ce70ff8:)
--> org.netbeans.modules.uml.core.support.umlutils.PropertyDefinition@0x7cddc188
(109 bytes) 

Additinaly there seems to be >500kB of org.dom4j data held in this map (without
counting String and other related stuff)
Comment 1 Antonin Nebuzelsky 2007-10-31 16:52:16 UTC
Reassigning for evaluation.
Comment 2 Viktor Lapitski 2007-11-02 18:58:15 UTC
the problems with significantly growing memory consumption due to leaked 
large dynamic project specific data like poject XML data or data structures 
associated with diagrams have been fixed in other IZ.
The problems left, like one here, is the data mostly used across the projects 
- its amount is several Mb and it doesn't grow or does it unnoticeable. 
Some of it are intended static elements of UML architecture, some are really 
bugs that would be possible to fix. At this moment weightning benefits vs. risk 
the bug is defferred.  
Comment 3 George Vasick 2008-06-10 17:11:03 UTC
Removing obsolete assignments.  Bugs will be reassigned for M2.
Comment 4 Sergey Petrov 2009-01-23 16:17:56 UTC
most issues was fixed, remaining have no much sense to fix, also issue with wording "leeking objects" with big set of
such objects almost impossible to fix (very wide area issue and may grow and grow etc), please file separate issues for
remaining ones if have sense.