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.
Summary: | Memory leak (~300kB) - Paste text in the Editor | ||
---|---|---|---|
Product: | ide | Reporter: | Marian Mirilovic <mmirilovic> |
Component: | Performance | Assignee: | Antonin Nebuzelsky <anebuzelsky> |
Status: | CLOSED FIXED | ||
Severity: | blocker | CC: | ttran |
Priority: | P2 | Keywords: | PERFORMANCE |
Version: | 3.x | ||
Hardware: | Sun | ||
OS: | Solaris | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | 49354, 49360 | ||
Bug Blocks: | 49230 | ||
Attachments: |
deltas (current memory size - minimal memory size) = leak
Difference of number of instances between steps 13) and 24) |
Description
Marian Mirilovic
2004-09-18 18:53:21 UTC
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 |