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.
[nb_beta2](200409091800), [jdk1.5.0](rc) Used memory size rises during Paste text in the Editor ~300 kB per open (see attached results xml file ) Steps to reproduce: ------------- 1. Open java1 file [20kB] 2. Open java2 file [20kB] 3. Select text from java1 file and from popup menu push Copy 4. Move cursor to java2 file and from popup menu push Paste|Copy EXPECTED RESULT: Text is pasted to java2 file within 100ms. -------------- Test case : http://www.netbeans.org/source/browse/performance/test/qa-functional/src/gui/action/PasteInEditor.java For more details see issue 49230.
Created attachment 17726 [details] deltas (current memory size - minimal memory size) = leak
-> Tonda
What I see in profiler to raise with each copy-paste operation is: * o.n.mdr.*, o.n.lib.java.parser and o.n.lib.gjast object instances (see my issue 48751 for details about increasing amount of these parser objects when reparsing a document and why it is not a leak) * o.n.editor.BasePosition, o.n.editor.MultiMark, other o.n.editor.*, o.o.text.PositionRef... object instances which must be created for the new lines to be drawn in the editor and for the paste action to be recorded for Undo-Redo * openide.nodes.* object instances representing the new methods and fields I will do investigation with the parser cache decreased to its minimum to see if the parser object instances are really the only ones which are "leaking" after the document is closed.
Honestly, the test does not prove the leak yet because the system is not in the same same between iterations. Rather it shows that Java editing does not scale well. What's happening in the test: 390 lines of code is selected in one file and repeatedly pasted into second file that grows to several thousands of lines during the test. Each paste takes a longer time and is followed with a long period of activity. Mostly processing of override anotations, firing events from src bridge and partialy setting new children to JavaNode. I tried similar test and pasting 256 lines of code comprising of 32 methods into 7000 lines long files generates >30MB of garbage and retains some memory as Marian reports.
Classes that occupies the biggest part of my heap when performing this test when a increased the size of file to almost 8000 lines (85MB memory of 128 used): org.netbeans.lib.gjast.ASName: 32816, 787584B org.openide.text.PositionRef: 32884, 789216B org.openide.text.PositionRef$Manager$PositionKind: 32884, 789216B org.netbeans.editor.BasePosition: 52840, 845440B [J: 34691, 850720B org.netbeans.lib.gjast.ASBlock: 16400, 918400B org.netbeans.lib.gjast.ASTreeNode: 32848, 1051136B org.openide.text.PositionRef$Manager$ChainItem: 32938, 1054016B java.util.ArrayList: 45674, 1096176B java.util.TreeMap$Entry: 35545, 1137440B org.netbeans.lib.gjast.ASModifiers: 24624, 1181952B org.netbeans.lib.gjast.ASMethodDef: 16400, 1312000B org.netbeans.editor.MultiMark: 57011, 1368264B com.sun.tools.javac.util.List: 98467, 1575472B org.netbeans.lib.gjast.ASIdent: 41008, 1968384B [B: 1385, 2095464B [Lorg.netbeans.lib.java.parser.ASTree;: 98449, 2428560B java.lang.Integer: 152848, 2445568B [I: 18318, 2857392B java.lang.String: 129676, 3112224B [Ljava.lang.Object;: 62319, 3300784B [Ljava.util.HashMap$Entry;: 14779, 3388576B [Lorg.netbeans.lib.java.parser.Token;: 205152, 4234880B java.util.HashMap$Entry: 275878, 6621072B org.netbeans.lib.java.parser.ScannerToken: 270944, 10837760B [C: 128030, 10944032B
> retains some memory as Marian reports The same for me. I ran the IDE with -J-Dorg.netbeans.javacore.ASTCache.size=1 to minimize the impact of increasing number of parsed ASTrees. First I've done a sequence just closely watching memory meter (doing tuns of explicit GCs) and got the following numbers: 1) 12.4MB - started IDE with the project 2) 15.0MB - opened 2 files 3) 15.0MB - selected text in one file 4) 15.2MB - copied text into clipboard 5) 16.0MB - ENTER + paste at the end of the second file 6) 15.5MB - copy 7) 16.5MB - ENTER + paste 8) 15.8MB - copy 9) 17.3MB - ENTER + paste 10)16.1MB - copy 11)17.9MB - ENTER + paste 12)15.5MB - CTRL+SHIFT+F4, discard 13)15.7MB - opened the 2 files 14)15.7MB - select 15)15.7MB - copy 16)16.3MB - ENTER + paste 17)15.8MB - copy 18)16.7MB - ENTER + paste 19)16.0MB - copy 20)17.3MB - ENTER + paste 21)16.3MB - copy 22)17.7MB - ENTER + paste 23)15.6MB - CTRL+SHIFT+F4, discard 24)15.9MB - opened the 2 files 25)16.2MB - repeated steps 14)-24) again So, there really seems to be a leak. I ran this procedure again with a profiler attached and the following attached snapshot shows the difference of number of instances between steps 13) and 24)... Suspicious is the growing number of instances of org.netbeans.modules.java.j2seproject.queries.CompiledSourceForBinaryQuery$Result and the growing number of classpath related objects (org.netbeans.api.java.classpath.ClassPath).
Created attachment 17764 [details] Difference of number of instances between steps 13) and 24)
Note that I filed separate issues #49354 and #49360.
Issues #49354, #49360 are fixed. Assuming this one is fixed.
verified