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 250690 - OutOfMemoryError: Big number of org.netbeans.modules.db.explorer.node.NodePropertySupport
Summary: OutOfMemoryError: Big number of org.netbeans.modules.db.explorer.node.NodePro...
Status: RESOLVED FIXED
Alias: None
Product: db
Classification: Unclassified
Component: Code (show other bugs)
Version: 8.0
Hardware: All All
: P3 normal (vote)
Assignee: matthias42
URL:
Keywords:
: 250775 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-02-25 13:16 UTC by idclaar
Modified: 2015-03-21 07:56 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter: 215664

Attachments
stacktrace (2.24 KB, text/plain)
2015-02-25 13:16 UTC, idclaar 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description idclaar 2015-02-25 13:16:13 UTC 
This issue was reported manually by thurka.
It already has 1 duplicates 


Build: NetBeans IDE 8.0 (Build nbms-and-javadoc-1932-on-20140722)
VM: Java HotSpot(TM) Client VM, 24.0-b55, Java(TM) SE Runtime Environment, 1.7.0_40-b40
OS: Windows 7

User Comments:
idclaar: While running sql expressions against a remote db server the IDE stopped responding.  I noticed that the IDE was slowly getting slower and slower over a period of about two hours while working on the stored procs and sql scratch expressions.  Seems like a leak.




Stacktrace: 
java.lang.OutOfMemoryError: Java heap space
   at java.awt.image.DataBufferInt.<init>(DataBufferInt.java:75)
   at java.awt.image.Raster.createPackedRaster(Raster.java:467)
   at java.awt.image.DirectColorModel.createCompatibleWritableRaster(DirectColorModel.java:1032)
   at java.awt.image.BufferedImage.<init>(BufferedImage.java:340)
   at com.sun.java.swing.plaf.windows.XPStyle$SkinPainter.createImage(XPStyle.java:673)
   at sun.swing.CachedPainter.paint0(CachedPainter.java:139)
Comment 1 idclaar 2015-02-25 13:16:16 UTC 
Created attachment 152209 [details]
stacktrace
Comment 2 Tomas Hurka 2015-02-25 13:22:38 UTC 
There are 1,498,167 instances of org.netbeans.modules.db.explorer.node.NodePropertySupport class
Comment 3 Tomas Hurka 2015-02-27 17:19:20 UTC 
*** Bug 250775 has been marked as a duplicate of this bug. ***
Comment 4 matthias42 2015-03-12 20:27:28 UTC 
Ok - there is an excessive number of nodes and node supporting classes created. NodePropertySupport is instantiated for each read-only property for each node.

Two things were done now:

- instantiate the node-comparators only once and not once per parent class (with 10.000 Tables this shaved approx. 10.000 instances off)
- The ActionRegistry was removed in favor of using org.openide.util.Utilities#actionsForPath ondemand that is another 10.0000 instances for my example
Comment 5 Quality Engineering 2015-03-14 05:47:42 UTC 
Integrated into 'main-silver', will be available in build *201503140001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/38f41cb275a6
User: Matthias Blaesing <matthias42@netbeans.org>
Log: #250690: don't instanziate db object comparators per parent node -> move them to static final instances
Comment 6 matthias42 2015-03-19 20:57:33 UTC 
I pushed two more changesets concluding the series for now. The two changes:

http://hg.netbeans.org/core-main/rev/b380fa1b40ac

Catalog-Nodes, Connection-Nodes and Schema-Nodes were held strongly by their property changelisteners on the database connection. These in turn held strong references to Table nodes. This change moves them to WeakListeners and now the nodes are correctly collected after connection disconnect.

http://hg.netbeans.org/core-main/rev/f3ca1c8c8b69

The private variable props held a list of _all_ NodePropertySupport object for the node. On each refresh the properties are refreshed via the addProperty method. This works for the sheet, which replaces the existing property, but the props list just got longer.

The solution: Don't use the list. The only method really using the list: getProperties, is never called in normal usage, so the properties are extracted from the property sheet on demand.

My tests with a 50 Tables DB showed this:

First Step:
1. Open db hierarchy until the tables are listed
2. call refresh on tables node 5 times
3. Issue an alter table command
4. call refresh on tables node once again

=> Take heap dump

Second Step:
5. refresh two times again

=> Take heap dump

This is the instance count for NodePropertySupport:

                            First step            Second Step
With out the patch:         5517                  7261
With the patch:             1164                  1164

I'll close the bug at this point. If there are still problem in the node/property handling I'll take another look, but then I'd need: the size of the db, preferably a heap dump.


If someone could verify my findings I would appretiate that!
Comment 7 Quality Engineering 2015-03-21 07:56:00 UTC 
Integrated into 'main-silver', will be available in build *201503210001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/b380fa1b40ac
User: Matthias Blaesing <matthias42@netbeans.org>
Log: #250690: Ensure property change listeners on connection are registered as WeakListeners