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.

Bug 98405 - Huge memory leak after opening Schema from SOA project - leads to OOME after second opening of the same file
Summary: Huge memory leak after opening Schema from SOA project - leads to OOME after ...
Status: VERIFIED FIXED
Alias: None
Product: xml
Classification: Unclassified
Component: Schema (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Samaresh Panda
URL:
Keywords: PERFORMANCE
: 86250 96043 (view as bug list)
Depends on: 100753 100866 102417 107555 107560
Blocks:
  Show dependency tree
 
Reported: 2007-03-20 23:34 UTC by Marian Mirilovic
Modified: 2008-01-25 00:16 UTC (History)
8 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
testing project (206.08 KB, application/x-gzip)
2007-03-20 23:35 UTC, Marian Mirilovic
Details
thread dumps during file opening (47.04 KB, text/plain)
2007-04-12 13:45 UTC, _ rkubacki
Details
snapshot1 (91.95 KB, application/octet-stream)
2007-04-30 20:16 UTC, Samaresh Panda
Details
snapshot2 (29.69 KB, application/octet-stream)
2007-04-30 20:25 UTC, Samaresh Panda
Details
snapshot3 (46.35 KB, application/octet-stream)
2007-04-30 20:26 UTC, Samaresh Panda
Details
snapshot4 (83.39 KB, application/octet-stream)
2007-04-30 20:26 UTC, Samaresh Panda
Details
snapshot5 (94.51 KB, application/octet-stream)
2007-04-30 20:30 UTC, Samaresh Panda
Details
heap-dump image (51.08 KB, application/octet-stream)
2007-06-21 02:03 UTC, Samaresh Panda
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marian Mirilovic 2007-03-20 23:34:35 UTC
Our automated performance tests are failing due to huge memory leak in Open
Schema View testcase. I tried to reproduce the same scenario manually and I
think I was successful :
- start IDE
- open attached SOA Project
- expand Process Files

memory : 30 MB
- select fields.xsd node (there is opened navigator view!)
memory : rises to 110MB - after few GC 70 MB
- select Process Files node
memory : force GC,GC,GC,GC,GC 70 MB 
- select fields.xsd node again
memory : force GC,GC,GC,GC,GC 75 MB !
...
- open fields.xsd file in editor
memory : force GC,GC,GC,GC,GC 87 MB (risen to 112 even if I do nothing with IDE
but still comes back to 90 MB)
- close fields.xsd editor window (still opened navigator)
memory : force GC,GC,GC,GC,GC 95 MB (risen to 125 MB !)
- open fields.xsd again -> causing Java Heap Space / Out Of Memory Error
Comment 1 Marian Mirilovic 2007-03-20 23:35:36 UTC
Created attachment 39724 [details]
testing project
Comment 2 Samaresh Panda 2007-03-21 23:56:25 UTC
*** Issue 96043 has been marked as a duplicate of this issue. ***
Comment 3 Marian Mirilovic 2007-03-22 08:40:09 UTC
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
Comment 4 _ rkubacki 2007-04-12 13:42:58 UTC
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.


Comment 5 _ rkubacki 2007-04-12 13:45:21 UTC
Created attachment 40819 [details]
thread dumps during file opening
Comment 6 Samaresh Panda 2007-04-12 16:46:43 UTC
Radim, I'm aware of it. I'm talking to people who know this better than me.
We'll keep you posted.
Comment 7 Samaresh Panda 2007-04-12 17:21:20 UTC
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.
Comment 8 Samaresh Panda 2007-04-13 00:14:04 UTC
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.
Comment 9 Samaresh Panda 2007-04-17 20:30:08 UTC
As per the i-team discussion, this is not considered a stopper for preview.
Comment 10 _ rkubacki 2007-04-20 10:22:11 UTC
- 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?
Comment 11 Rashid Urusov 2007-04-23 16:17:07 UTC
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.
Comment 12 Samaresh Panda 2007-04-24 06:53:28 UTC
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.
Comment 13 Samaresh Panda 2007-04-25 01:52:47 UTC
HintsUI keeps a strong reference to the UI, which in turn keeps the model alive.
See 102417.
Comment 14 Petr Blaha 2007-04-26 16:46:41 UTC
What's the status of this issue? Do you plan to fix it to M9? Thanks.
Comment 15 Samaresh Panda 2007-04-26 17:29:53 UTC
The issue depends on 102417.
Comment 16 Petr Blaha 2007-04-26 19:55:26 UTC
OK, but issue #102417 is P2 and only P1 stoppers would be fixed now for M9. 
Comment 17 _ rkubacki 2007-04-26 21:13:49 UTC
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.

 
Comment 18 Samaresh Panda 2007-04-27 17:44:06 UTC
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.
Comment 19 Samaresh Panda 2007-04-27 18:36:43 UTC
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.
Comment 20 Pavel Buzek 2007-04-27 18:47:50 UTC
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.
Comment 21 Petr Hrebejk 2007-04-27 19:00:16 UTC
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.
Comment 22 Samaresh Panda 2007-04-27 19:05:49 UTC
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.
Comment 23 Petr Hrebejk 2007-04-27 19:50:30 UTC
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. 
Comment 24 Samaresh Panda 2007-04-27 20:15:33 UTC
Of course, I didnt want you to decide. People who made this a stopper for J1,
they are to decide, not you.
Comment 25 Petr Hrebejk 2007-04-27 20:43:35 UTC
Of course. Thanks. :-)
Comment 26 Pavel Buzek 2007-04-27 20:50:36 UTC
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.
Comment 27 Marian Mirilovic 2007-04-30 09:06:34 UTC
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


Comment 28 Samaresh Panda 2007-04-30 20:16:44 UTC
Created attachment 41980 [details]
snapshot1
Comment 29 Samaresh Panda 2007-04-30 20:18:22 UTC
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.
Comment 30 Samaresh Panda 2007-04-30 20:24:08 UTC
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.
Comment 31 Samaresh Panda 2007-04-30 20:25:32 UTC
Created attachment 41981 [details]
snapshot2
Comment 32 Samaresh Panda 2007-04-30 20:26:00 UTC
Created attachment 41982 [details]
snapshot3
Comment 33 Samaresh Panda 2007-04-30 20:26:32 UTC
Created attachment 41983 [details]
snapshot4
Comment 34 Samaresh Panda 2007-04-30 20:29:27 UTC
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.
Comment 35 Samaresh Panda 2007-04-30 20:30:27 UTC
Created attachment 41984 [details]
snapshot5
Comment 36 Samaresh Panda 2007-06-21 02:01:59 UTC
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.
Comment 37 Samaresh Panda 2007-06-21 02:03:21 UTC
Created attachment 44127 [details]
heap-dump image
Comment 38 Samaresh Panda 2007-06-21 02:27:17 UTC
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.
Comment 39 Samaresh Panda 2007-06-21 20:05:07 UTC
*** Issue 86250 has been marked as a duplicate of this issue. ***
Comment 40 _ rkubacki 2007-08-02 16:10:38 UTC
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
Comment 41 Rashid Urusov 2007-08-06 14:10:38 UTC
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
Comment 42 tonybeckham 2008-01-14 22:41:23 UTC
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.
Comment 43 Samaresh Panda 2008-01-15 00:06:59 UTC
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.
Comment 44 tonybeckham 2008-01-25 00:16:17 UTC
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.