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.
1. Start 6.1 with no userdir, NB ends up with about 160Mb (measured by task manager) 2. Subsequent starts -> 150Mb 1. Start 6.1 with no userdir, NB ends up with about 160Mb 2. Exit and delete var/cache/catalogcache in userdir 3. Subsequent starts -> 110Mb was in 6.0: 1. Start 6.0 with no userdir, NB ends up with about 125Mb 2. Subsequent starts -> 115Mb 1. Start 6.0 with no userdir, NB ends up with about 125Mb 2. Exit and delete var/cache/catalogcache dir 3. Subsequent starts -> 100Mb => Difference for 6.0 for subsequent starts is 115-100=15Mb and for 6.1 150-110=40Mb
There no changes in Autoupdate Services code between NB6 FCS and NB6.1 trunk thus there cannot be any regression.
Well, there can be, caused by the size of the catalog for given version. Still, we need to check why does AU client cause such a large difference (between disabled and enabled, not between 6.0 and 6.1) and how to avoid it.
Hugh part of consumption is caused by parsing 5MB xml document but this memory is released after that. New tests about that will be added soon. But, some memory leak was found out in Autoupdate UI, I'm evaluating it now.
Tests: http://hg.netbeans.org/main/rev/5b2289d84de0
Fixed a memleak in Autoupdate UI (since NB6.1M1): See http://hg.netbeans.org/main/rev/5e93829357c6 It means whole memory heap occupied by Autoupdate is allocated temporary only and it can be gc-ing when Autoupdate UI is closed, moreover DOM memory is released just after build Autoupdate data model => can be decreased to P3 at least.
One more observation (in today dev build): when I disable the two update centers in the plugin manager I get much lower memory consumption after startup. It's like 130MB vs 190MB i.e. 60MB difference (seen in task manager, but the same difference can be seen in allocated size of heap). If I keep the update centers enabled and just set "Check Interval" to "Never", I still get the high memory consumption after startup. This is weird, it looks like the catalog is still loaded into memory - but there is no reason in this case. I don't open plugin manager - so why anything around it should be touched? Only if I disable the AU centers as I described, the memory consumption goes down. Another question is if we really need 60MB in memory to process data about 100 plugins... What if we have 1000 plugins one dya? Will it need 600MB?
Answering myself - as for 60MB for 100 plugins, there's actually much more modules than 100 - this number is just visible as available for installation in the plugin manager, but all modules from the IDE are also included in the catalog and they are grouped in the UI, so there can be several hundreds of modules technically. Still there is a visible difference in memory consumption compared to 6.0. The question if we should try to avoid using so much memory during startup (or just after it), or if it is not a big problem. I'm probably more worried about the amount of work done just after startup which is quite overloaded period.
*** Issue 121673 has been marked as a duplicate of this issue. ***
moving opened issues from TM <= 6.1 to TM=Dev
*** Issue 137778 has been marked as a duplicate of this issue. ***
fixed. DOM parser was replaces by SAX parser in changeset c3671f6adc67
*** Issue 124482 has been marked as a duplicate of this issue. ***
Integrated into 'main-golden', available in build *200808120201* on http://bits.netbeans.org/dev/nightly/ Changeset: http://hg.netbeans.org/main/rev/c3671f6adc67 User: Jiri Rechtacek <jrechtacek@netbeans.org> Log: #126206: High memory consumption increase with AU client
v. in 200808120201
Build: NetBeans IDE Dev (Build 200808241401) VM: Java HotSpot(TM) Client VM, 1.6.0_02-b06, Java(TM) SE Runtime Environment, 1.6.0_02-b06 OS: Windows XP, 5.1, x86 User Comments: hi got this exception when I run the help->check updates Stacktrace: java.lang.OutOfMemoryError: Java heap space at com.sun.org.apache.xerces.internal.util.XMLStringBuffer.append(XMLStringBuffer.java:205) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.refresh(XMLDocumentScannerImpl.java:1493) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.invokeListeners(XMLEntityScanner.java:2070) at com.sun.org.apache.xerces.internal.impl.XMLEntityScanner.skipChar(XMLEntityScanner.java:1415) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2777) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:645)
Created attachment 68225 [details] stacktrace
*** Issue 145139 has been marked as a duplicate of this issue. ***
Build: NetBeans IDE Dev (Build 200808261401) VM: Java HotSpot(TM) Client VM, 10.0-b19, Java(TM) SE Runtime Environment, 1.6.0_05-b13 OS: Windows XP, 5.1, x86 User Comments: deployed a web project that has several thousand html and JS files (Dojo framework) Stacktrace: Root: D:\projects\ITMS\grc-libs\code\libs\web File: XhrIframeProxy.js Bootpath: ClassPath[] Classpath: ClassPath[] Sourcepath: ClassPath[Entry[file:/D:/projects/ITMS/grc-libs/code/libs/web/]]
Created attachment 68533 [details] stacktrace
Still happens after startup of module suite, see attached project.
Created attachment 70025 [details] Suite project
I guess that comment doesn't belong to this issue => closed as fixed again. ------- Additional comments from rmichalsky Wed Sep 17 11:01:36 +0000 2008 ------- Still happens after startup of module suite, see attached project.
Not fixed for Build 200809220201. See: http://statistics.netbeans.org/analytics/detail.do?id=118227
Created attachment 70547 [details] log file
closing this bug as fixed again. Ulf's problem will be tracked as issue 148324.
Reopening - reproduced in NetBeans IDE Dev (Build 200810071401) http://statistics.netbeans.org/exceptions/detail.do?id=125027
We did our best in this issue. Further improvement is currently tracked as a issue 148324.