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.