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.
I tried to run JProfiles several times after opening / closing a XML file and realized that there is a DocumentModel instance in memory leaking. It has hardlinks to Document instance and plenty of DocumentElements. It also causes a performance problem after several closing / opening of the same file.
I will try to fix it ASAP...
After a few hours spent in imagination of where can be the damned reference to the DocumentModel instance and thinking about the weekness of the world I realized that the problem is on the editor side :-). Then I tried to profile memory for other editor types and realized that the problem happed for all of them (I tried XML/DTD/java/plain). I am attaching a screenshot of the profiler where is clearly visible that a plenty of instancies connected to NbEditorDocument is allocated and cannot be garbage collected. How I tested the leak: 1) open a plain text document in the editor 2) close it => 2 new instancies of NbEditorDocument + tons of related objects are allocated and hard-referenced somehow (I didn't go throught all of the reference graphs) 3) open the document again 4) close it again => next 2 new instancies + plenty of thers I tried to run GC after the open/close several times, but the objects are not GCed. Reassigning to editor.
Created attachment 24565 [details] Screenshot of the profiler window
I am not sure whether the priority is set correctly - quite big amount of memory can leak for some editor types. Radime, can you please take look at it?
I am a bit busy these days but I will try.
Marku, thanks for finding this. It is P1, must fix for Beta. The size of the leak is large. It can be a few megs for some of the newly opened files (sometimes it is less), but also hundreds of kilobytes for each file reopening. Editor team, please, evaluate ASAP.
Reassigning to Honza B.
Honza doesn't have installed profiler, so I will take this.
I suspect that it could be related to listening on MimeLookup. The listener on MimeLookup's result should be weak as the result can be referenced by multiple objects and some of them can be alive.
just subject change
Leak is caused by this integration: Directory: /editor/src/org/netbeans/modules/editor/ =================================================== File [changed]: NbEditorUI.java Url: http://editor.netbeans.org/source/browse/editor/src/org/netbeans/modules/editor/NbEditorUI.java?r1=1.35&r2=1.36 Delta lines: +132 -2 --------------------- --- NbEditorUI.java 12 Aug 2005 15:15:58 -0000 1.35 +++ NbEditorUI.java 26 Aug 2005 12:22:22 -0000 1.36
Checking in org/netbeans/modules/editor/NbEditorUI.java; /cvs/editor/src/org/netbeans/modules/editor/NbEditorUI.java,v <-- NbEditorUI.java new revision: 1.40; previous revision: 1.39 done
I tried to reproduce it and check what INSANE can do. Here is simple to do list. - add insane module to the IDE. 'ant -f performance/insane/build.xml' - run the IDE and reproduce the leak (open/close few files) and then generate a dump - create a simple project depending on performance/insanelib, use modified version of DemoQuery contained in performance/insanelib/demo to find instances of NbEditorDocument and their traces from root - analyze the output
Created attachment 24638 [details] INSANE output
leaks through anonymous inner class in NbEditorUI held from MIME lookup are visible in the output
Verified with profiler as fixed. Thanks!