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: | Huge memory leak after opening Schema from SOA project - leads to OOME after second opening of the same file | ||
---|---|---|---|
Product: | xml | Reporter: | Marian Mirilovic <mmirilovic> |
Component: | Schema | Assignee: | Samaresh Panda <samaresh> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | blaha, issues, mrkam, pbuzek, phrebejk, pjiricka, rashid, rkubacki |
Priority: | P2 | Keywords: | PERFORMANCE |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | 100753, 100866, 102417, 107555, 107560 | ||
Bug Blocks: | |||
Attachments: |
testing project
thread dumps during file opening snapshot1 snapshot2 snapshot3 snapshot4 snapshot5 heap-dump image |
Description
Marian Mirilovic
2007-03-20 23:34:35 UTC
Created attachment 39724 [details]
testing project
*** Issue 96043 has been marked as a duplicate of this issue. *** comment from issue 96043 points to issue 94236 & comment from issue 94236: ------- Additional comments from girixkumar Tue Feb 6 03:43:14 +0000 2007 ------- .... the fix might not take care of the memory leaks I tried to run BIG ide with -J-Xmx160m -J-XX:+HeapDumpOnOutOfMemoryError -J-XX:HeapDumpPath=/usr/local/java and can get heap dump quickly when opening the file so it should be possible to analyze what causes high peak on .xsd file opening. Personally I do not understand what DiffFinder is doing in this case - the file is not modified so there is no point to create set of differences. This computation is very expensive - it parses whole document and creates large data structures. - we have too large structure of org.netbeans.modules.xml.xdm.nodes.* objects connected together by many collections and holding tons of String. Petr N. already had some idea how to optimize these - DiffFinder is computing another large data structure that can be subject of optimization. OTOH I do not understand why it computes any diff in this case. I'll attach related stack trace. I believe we can move further if we kill this processing. Created attachment 40819 [details]
thread dumps during file opening
Radim, I'm aware of it. I'm talking to people who know this better than me. We'll keep you posted. Also I don't see a leak after 2nd open/close of the file. I do see that after the first open/close. Seems like a top component is not getting collected. I need a better tool to find out who is holding onto it. Hopefully I will have some more information/fixes later today. JavaSource in java/source keeps a strong reference to the last editor, hence the memory leak in opening/closing of schemas. Try this: - Start NB, note the memory situation - Open/cose fields.xsd, you'll see memory goes up. - Now open/close a java class file. - You'll see memory goes down to the original state. My guess is that, the lastEditor filed keeps a strong reference to the last editor and as soon as the last editor is changed to something else, memory gets released. I have filed an issue against it. See 100866. As per the i-team discussion, this is not considered a stopper for preview. - navigator is too eager - I need 35+MB of data on heap to see fields.xsd in it. And it need at least 45MB in its peak when it is processing the data - then I try to open the editor and it eats another 25+MB for this editor and the peak is even worse here Assuming that fixed #100866 helps to clear memory sooner after editor close: How are going to reduce the memory consumption during these operations? I performed measurements with build NetBeans IDE Dev (Build 070423) 1.6.0_01; Java HotSpot(TM) Client VM 1.6.0_01-b06 Windows XP version 5.1 running on x86 en_US (nb); Cp1252 There are results: - start IDE - open attached SOA Project - expand Process Files memory : 29 MB - select fields.xsd node (there is opened navigator view!) memory : rises to 76,2MB - after few GC 56 MB - select Process Files node memory : force GC,GC,GC,GC,GC 55,5 MB - select fields.xsd node again memory : force GC,GC,GC,GC,GC 55,5 MB ... - open fields.xsd file in editor memory : force GC,GC,GC,GC,GC 78 MB (risen to 85 even if I do nothing with IDE but still comes back to 78,2 MB) - close fields.xsd editor window (still opened navigator) memory : force GC,GC,GC,GC,GC 77,5 MB (risen to 85 MB ) - select fields.xsd node (there is opened navigator view!) and right click mouse after context menu appeared memory : rises to 95,6MB - open fields.xsd again memory : force GC,GC,GC,GC,GC 79,3 MB (risen to 89,7 MB even if I do nothing with IDE but still comes back to 81 MB) - close fields.xsd editor window (still opened navigator) memory : force GC,GC,GC,GC,GC 78 MB (risen to 85,8 MB ) - select fields.xsd node (there is opened navigator view!) and right click mouse after context menu appeared memory : rises to 96,2MB - open fields.xsd again memory : force GC,GC,GC,GC,GC 106,2 MB (risen to 114 MB even if I do nothing with IDE but still comes back to 106,8 MB) - close fields.xsd editor window (still opened navigator) memory : force GC,GC,GC,GC,GC 106,6 MB (risen to 107,5 MB ) - select fields.xsd node (there is opened navigator view!) and right click mouse after context menu appeared memory : rises to 120MB - open fields.xsd again - schema is opened in source view. after switch schema to design view -> causing Java Heap Space / Out Of Memory Error REMARK: While I force GC after right click mouse on schema node and context menu appeared but before click on open schema item I could operate with schema (open/close) without to be faced with Out Of Memory Error . Maybe here is a bottle neck. 1. Explanation to Diff: The model gets created from the document buffer and every time a file is re-opened, it is necessary to sync the model with the new document buffer, even if there is no change. In order to sync, we need to calculate the diff, in this case, it happens to be very expensive. 2. As far as memory consumption is concerned, here are the stats on HL7: char[] consumes ~21mb String consumes ~7mb xdm (and rest) ~7mb Note that fileds.xsd schema pulls in datatypes.xsd as a result of schema import. 3. As for the memory leak, I am working on it. The difficult part is, analyzing the heapdump. None of the tools (jhat, nb-profiler, optit4.2) clearly indicate who holds on to the references I'm interested in. I found Optit6.0 be the best, unfortunately the trial on it expired. HintsUI keeps a strong reference to the UI, which in turn keeps the model alive. See 102417. What's the status of this issue? Do you plan to fix it to M9? Thanks. The issue depends on 102417. OK, but issue #102417 is P2 and only P1 stoppers would be fixed now for M9. samaresh: while I agree that retained last editor is not a nice thing this is not the biggest problem in this bug. We have growing memory usage when we repeat: select node, open its editor, close this editor, select another node. It means that bugs that you have filled - #100866 & #102417 should not be critical (they are serious because the memory usage for one iteration of these steps is too high). These paths holds only one last editor so they do not accumulate. Also note that there is also #100755 and even if we fix this it is likely that there will be couple of other like list cell renderers used for code completion, Swing input method handling and so on. Ironically 102417(originally P1, was later made P2) got closed as a duplicate of 100753, which was a P3. I have updated 100753 as a P1( stopper). If that gets fixed, there is a high chance that this will also get fixed. 100753 has again been made a P3. Someone "strongly disagrees" that a memory leak is not a problem for J1. The original bug is about is memory leak in schema editor and it highly depends on 100753. The last comment from samaresh says there is a "high chance" that 100753 will fix this issue, but it's in direct contradiction with Radim's last comment. Radim suggests this is not the most important issue in this case. Here is the somebody who strongly disagrees. The reasons why I disagree are listed in the #100753. IMO there is very little if no at all chance to fix this when #100753 gets fixed. Memory usage is a different problem than a memory leak. The underlying model is xdm and is core to all other models, e.g schema, axiom, bpel, wsdl. I do not recommend making any changes to xdm at this point. We have two choices: 1. Fix issue 100753 for J1 OR 2. Waive this one for J1. I leave it upto you to decide. Obviously a compete nonsense as I explain in the #100753 there is no chance that fixing it fixes this. And you don't seem to have any reason to think so either. I'm not going to decide what you should do with this bug. Of course, I didnt want you to decide. People who made this a stopper for J1, they are to decide, not you. Of course. Thanks. :-) I think there are two separate issues:
1. If this is a blocker for Java One, that is up to QA to decide.
2. How to solve this issue. That is up to you to resolve. Both Radim and Petr
Hrebejk are just telling you that out of the options that you offer
> We have two choices:
> 1. Fix issue 100753 for J1 OR
> 2. Waive this one for J1.
the first is not a solution for this problem. So I guess you have no solution.
So, we are very close to J1 and I measured it once again (after some of related issues were fixed). So let's go : memory 30MB - select fields.xsd node (there is opened navigator view!) memory: rises to 70 MB - after few GC 62 MB - select Main.java from sample project (to force navigator refresh) memory: after few GC 33 MB - select fields.xsd node memory: rises to 83 MB - after few GC 62,3 MB - select Main.java memory: after few GC 33,4 MB - select fields.xsd node memory: rises to 83 MB - after few GC 62,5 MB - select Main.java memory: after few GC 33,5 MB - select fields.xsd node memory: rises to 85 MB - after few GC 62,6 MB - select Main.java memory: after few GC 33,5 MB so it looks like there is small memory leak during selecting the node (200/300 kB) opening file : - open fields.xsd node (already selected so navigator shows the content) memory: rises to 110 MB - after few GC 85 MB - close fields.xsd memory: after few GC 85 MB (means nothing was garbage collected - Runtime watches show 1 document in memory) ! - open fields.xsd node memory: rises to 155 MB - after few GC 115 MB - close fields.xsd memory: after few GC 115 MB (Runtime watches - 2 documents) - open fields.xsd node memory: rises to 175 MB - after few GC 118 MB - close fields.xsd memory: after few GC 115 MB (Runtime watches - 2 documents) - open fields.xsd node memory: rises to 175 MB - after few GC 115 MB - close fields.xsd memory: after few GC 86 MB (Runtime watches - 1 document) From the data above : I think once I got into state when the whole document was in the memory three times but after few GCs (two of them got garbaged). In this light I agree with waiving this issue for J1, but it has to be fixed for NB 6.0 Created attachment 41980 [details]
snapshot1
That was just theory, now I created heap-dumps of these use cases and I would like to present them here. Use case 1: Select schema nodes, java files etc on project tab as many times you want. Do not open any file yet. Here is the snapshot of all xml instances. Either these are static instances or singleton instances. See snapsho1. Use case 2: Open/close, open/close as many schemas and at the end of it, an analysis of various instances that are not expected on the heap. See snapshot2, snapshot3 and snapshot4. They all point to JavaSource->editorRegistryListener. Created attachment 41981 [details]
snapshot2
Created attachment 41982 [details]
snapshot3
Created attachment 41983 [details]
snapshot4
Use case 3: Open/close, open/close as many schema and finally just open a Java file. The leak is apparently gone and all you see is the static and singleton instances, same as snapshot1. Compare snapshot5 with snapshot1. Created attachment 41984 [details]
snapshot5
Wrote up a unit test explicitly to get the heap dump when hl7 schema file is loaded. I wish there was a way to attach this dump file. See attached heap-dump image. Created attachment 44127 [details]
heap-dump image
This unit test was run outside the ide (not sure if that helps). Some data from the dump: - ~8mb of org.netbeans.editor.ext.ExtSyntaxSupport$TokenItemTP$Item. See 107555. - ~10mb of char[], out of which two char[] are of ~2mb each. See 107560 for one. Am trying to figure out the other. - ~5mb of String. - A lot of String, char[] and Object[] instances are emanating from ExtSyntaxSupport$TokenItemTP$Item. *** Issue 86250 has been marked as a duplicate of this issue. *** Seems to be working in 128m heap now. The memory usage is still very high but perhaps the priority can be decreased or we can file separate bugs to request better memory usage: 1) memorylint still shows several MB in duplicated string 2) there are interesting places like o.n.m.xml.text.folding.XmlFoldingManager that is holding 300kB large empty Object[] in 'changes' Vector, maybe there are more places like this Switching to other tabs is again creating a lot of objects. 3) Code completion in this document is extremely slow. 4) Cursor navigation is slow (matching tag highlighting?) 5) Code completion takes +10 secs as well in text editor Priority is decreased due to disappearance of OOME. But opening fields.xsd schema takes too long time that shows automated perormance tests: http://xtest-db.czech.sun.com/AllInOnePerformanceDashboard/atomicResult.jsp?project=nb_bigide_Dev&buildNumber=200708050000&suiteName=Actions&resultName=Open%20Complex%20Schema%20View System info: Product Version: NetBeans IDE Dev (Build 200801090000) Java: 1.6.0_04; Java HotSpot(TM) Client VM 10.0-b19 System: Linux version 2.6.22-14-generic running on i386; UTF-8; en_US (nb) Since OOME is no longer an issue I believe this issue should be closed. Other issues should be tracked seperately. Many mentioned in this issue already are/have been. Originally the issue was on memory leak. If all the leaks (see depends on) have indeed been resolved, we should no longer see leaks. As far as memory consumption is concerned: 1. xdm has been migrated to use lexer (see issue 124589) So issues related to TokenItem (issue 107555) doesn't block this anymore. Also there is some optimization done in xdm. Used to consume more than 30mb on fields.xsd, now it consumes about 22mb. See testXDMModelSize in XDMModelTest. 2. There is another data structure (DocumentModel for fold) that comes into play while opening xml/schema files. There is a plan (issue 125055) to use xdm (??) for this and if we do, we should gain a lot and answers point #2 mentioned by radim - Aug 2. 3. For CC inside such big documents, we already have issues filed. See issue 114798. I agree, we should close this and track individual issues mentioned here. Verified: Product Version: NetBeans IDE Dev (Build 200801220251) Java: 1.5.0_13; Java HotSpot(TM) Client VM 1.5.0_13-119 System: Mac OS X version 10.5.1 running on i386; MacRoman; en_US (nb) Additional issues defined in this issue should be tracked separately. See comment from samaresh on Tue Jan 15 for more information. |