Running a dev build w/

org.netbeans.modules.editor.highlights/0 [1.0 060426]
org.netbeans.modules.spellchecker [1.1 060428]

Found that after opening dozens of Java sources from various modules, but then
closing all those modules, heap was still high (~ 160m). No projects loaded but
much MDR stuff loaded. Ran jhat and found many leaks like this one:

Static reference from
org.netbeans.modules.editor.highlights.HighlighterImpl.INSTANCE (from class
org.netbeans.modules.editor.highlights.HighlighterImpl) :
--> org.netbeans.modules.editor.highlights.HighlighterImpl@0x7db58a08 (20 bytes)
(field fo2Comp:)
--> java.util.WeakHashMap@0x7db6cd08 (44 bytes) (field table:)
--> [Ljava.util.WeakHashMap$Entry;@0x856cc088 (2056 bytes) (Element 200 of
[Ljava.util.WeakHashMap$Entry;@0x856cc088:)
--> java.util.WeakHashMap$Entry@0x81d43e98 (36 bytes) (field value:)
--> java.util.ArrayList@0x81d47b60 (20 bytes) (field elementData:)
--> [Ljava.lang.Object;@0x81d4eae8 (48 bytes) (Element 0 of
[Ljava.lang.Object;@0x81d4eae8:)
--> org.openide.text.QuietEditorPane@0x81d46cb0 (451 bytes) (field changeSupport:)
--> java.beans.PropertyChangeSupport@0x81d4d708 (24 bytes) (field listeners:)
--> sun.awt.EventListenerAggregate@0x81d543b8 (12 bytes) (field listenerList:)
--> [Ljava.beans.PropertyChangeListener;@0x85084dd0 (40 bytes) (Element 2 of
[Ljava.beans.PropertyChangeListener;@0x85084dd0:)
--> org.netbeans.modules.spellchecker.ComponentPeer@0x81d524b0 (37 bytes) (field l:)
--> org.netbeans.modules.spellchecker.bindings.java.JavaTokenList@0x81d59e90 (40
bytes) (field doc:)
--> org.netbeans.modules.editor.NbEditorDocument@0x81d47420 (200 bytes) (field
syntaxSupport:)
--> org.netbeans.modules.editor.java.NbJavaJMISyntaxSupport@0x81d4de38 (54
bytes) (field jmiUtils:)
--> org.netbeans.modules.editor.java.JMIUtils@0x8504ec38 (21 bytes) (field
resource:)
--> org.netbeans.jmi.javamodel.Resource$Impl@0x82cd69a0 (95 bytes) (field
classifiers:)
--> org.netbeans.modules.javacore.jmiimpl.javamodel.LightAttrList@0x82cd9128 (36
bytes) (field hardReferences:)
--> java.util.ArrayList@0x8507e588 (20 bytes) (field elementData:)
--> [Ljava.lang.Object;@0x8507f380 (12 bytes) (Element 0 of
[Ljava.lang.Object;@0x8507f380:)
--> org.netbeans.jmi.javamodel.JavaClass$Impl@0x82cd7b70 (86 bytes)

org.netbeans.modules.spellchecker.ComponentPeer may be partially at fault, since
it attached a PropertyChangeListener to a JTextComponent and never removes it,
but perhaps this peer is really supposed to live as long as the component. Real
leak seems to be in org.netbeans.modules.editor.highlights.HighlighterImpl. Note

WeakHashMap<JTextComponent,FileObject> comp2FO;
WeakHashMap<FileObject,ArrayList<JTextComponent>> fo2Comp;

If you think about this for a moment you will see that after anything is
registered here, neither the FO nor the JTC(s) can ever be collected unless the
HighlighterImpl is collected! (Which is won't, since it is a statically held
singleton.) Suggest perhaps

WeakHashMap<JTextComponent,FileObject> comp2FO;
WeakHashMap<FileObject,WeakSet<JTextComponent>> fo2Comp;

which should permit the cycle to be broken.