Running on JDK 1.6.0_01:
The ColoringMap.CACHE field appears to be the root of a memory leak. To
1) Create a java project and create a JPanel form
2) Switch to the java source tab (this step may not be necessary)
3) Close the editor windows
4) Close the project
5) Use jmap or a memory profiler to get the heap dump
The org.netbeans.modules.form.FormDataNode object is still in memory and is
indirectly being held by this map. This issue is also a problem with visual web
Can you please attach the references gpraph? Thanks.
Created attachment 42659 [details]
Heap dump reference graph
Attached is a snapshot of the reference graph from the heap dump. It shows the
ColoringMap.CACHE field reference up to the leaking NbEditorUI object.
Ok, I'll have a closer look.
*** Issue 104332 has been marked as a duplicate of this issue. ***
*** Issue 105083 has been marked as a duplicate of this issue. ***
The EditorUI is held through its listener. The problem only happens with multi
views, eg. form editor. The reason for that is that multiviews do not call
CloneableEditor.canClose like normal editors and that calling CE.canClose has a
side effect of cleaning up the associated JEditorPane.
The normal sequence of events (as it is expected by the editor infrastructure)
1. create JEP
2. set JEP's editor kit -> kit.install(JEP)
3. use JEP
4. reset JEP's editor kit to null -> kit.deinstall(JEP)
The kit.install/deinstall methods are main hooks for the editor infrastructure
where a lot of editor stuff is added/removed. Among other things EditorUI is
created and adds/removes its listener on ColoringMap.
The above steps are what should happen and also normally happens, most of it is
done in CloneableEditor. When using multiview #4 does not happen, because nobody
calls CloneableEditor.canClose, MultiViewElements have their own special way of
telling if they can be closed. The real question I think is, why #4 is done in
CE.canClose and not for example in CE.componentClosed.
I'll try the outlined possibility.
until this gets fixed, individual classes extending CE can do the reset editorkit, to release memory.
I'm testing the proposed fix now.
BTW: There seems to be another (minor) leak related to ColoringMap.CACHE:
It uses WeakHashMap, but its values (ColoringMap) reference its (otherwise weak) keys (MimePath) through
ProxyLookup$R lookupResult -> MimePathLookup this$0 -> MiMePath mimePath.
MemoryLint's "Leaking WeakHashMap" rule discovers this problem (in several similar instances) easily.
Fixed as outlined: