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.
Once AU connects to the AU server, it keeps the XML updates parsed ad DOM in memory. It also keeps DummyModuleInfo and everything necessary, which accounts for ~2MB with current AU size (~190 modules listed). I understand AU is going to be completely rewritten, so consider this issue a friendly remainder of known problem and a notice we need to evaluate new AU for memory consumption.
I hoped this problem will cease to exist with new Plugin Manager, but it seems it got replaced with similar problem. With the new manager, after looking at the UI and closing it (so it is probably no longer caused just by starting the IDE while having netbeans.org reachable), there were 11MB in two char[] left on my heap (and also bunch of DOM structures, but they were not that significant compared to this ;-) ) The arrays are reachable through DOMParser instance, which is kept in some ThreadLocals, keyed from XMLUtil.builerTL. This might be the real source of the problem.
part of fix #98168: Autoupdate keeps too much data in memory; don't hold references into DOM Checking in SimpleItem.java; /shared/data/ccvs/repository/autoupdate/services/src/org/netbeans/modules/autoupdate/updateprovider/SimpleItem.java,v <-- SimpleItem.java new revision: 1.3; previous revision: 1.2 done
One more fix SimpleItem.java; /shared/data/ccvs/repository/autoupdate/services/src/org/netbeans/modules/autoupdate/updateprovider/SimpleItem.java,v <-- SimpleItem.java new revision: 1.4; previous revision: 1.3 done
I tried to workaround the xml leak (issue 101103) and repeat the measurement. Still, the memory isn't freed after closing plugin manager. The UpdateManagerImpl keeps a lot of info (UpdateUnit->UpdateItem->ModuleItem) in memory even after closing the UI. This info is quite expensive, as the module licenses alone (linked from ModuleItem) consume over 1.5MB Is it necessary to keep all the info all the time? I believe not. Caching the (downloaded as compressed) catalog on disk and parsing it again on demand should be fast enough.
This leak is still there and consuming more than 2MB of the heap. It will get more pronounced with the plugin portal and more available modules. Leak -> P2
UpdateManager shouldn't be singleton but replaced by factory. Then instance of UM may holds instance of UpdateUnits which disappears when instance of UM will be released.
*** Issue 113959 has been marked as a duplicate of this issue. ***
/cvs/autoupdate/services/src/org/netbeans/modules/autoupdate/services/UpdateUnitProviderImpl.java,v <-- new revision: 1.21; previous revision: 1.20 /cvs/autoupdate/services/src/org/netbeans/modules/autoupdate/services/UpdateManagerImpl.java,v <-- new revision: 1.14; previous revision: 1.13 /cvs/autoupdate/services/test/unit/src/org/netbeans/modules/autoupdate/services/UpdateManagerImplTest.java,v <-- new revision: 1.4; previous revision: 1.3 /cvs/autoupdate/services/test/unit/src/org/netbeans/modules/autoupdate/services/InstallEagerModuleTest.java,v <-- new revision: 1.8; previous revision: 1.7 /cvs/autoupdate/services/test/unit/src/org/netbeans/api/autoupdate/DefaultTestCase.java,v <-- DefaultTestCase.java new revision: 1.9; previous revision: 1.8