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.
Several people in NetCAT program reported that there are problems with incredible memory consumption. After some time the IDE takes twice more than what it started with and occasionaly also OutOfMemoryExceptions occur. The only workaround is to restart NetBeans, because Garbage Collector does not help. What would you need to know more in order to get rid of this habbit ?
Hi all, we need as much info as you can provide, like : used JDK, IDE build number, scenarios, your workflow (aka using CVS, opening a lot of java files, debugging, JSP editing, GUI editing, ..... ), HW configuration (memory size), OS, additional modules, switches, ..... Thanks for cooperation ;)
Hi Marian, I experienced this bug, and added all the information at http://www.netbeans.org/issues/show_bug.cgi?id=40229.
Assigning to performance component until we find a culprit of the problem.
I'm adding my comments from the NetCAT forum: This isn't an issue related solely to 3.6 but it does continue the behavior I've seen in previous versions. When I start the IDE and open my project the IDE takes about 83MB of memory and 110MB of Virtual Memory, as viewed in the windows task manager. By the end of the day it is at 180MB mem and 210MB VM, the only way to free the memory is to quit the IDE, changing projects doesn't help, manual garbage collection will reduce the usage a little bit, but only for a little while. I have been able to slow the process by adding -Xmaxf .15 -Xminf .10 to ide.cfg but it always grows....if I leave the it running long enough (only happened once or twice) I will start getting out of memory exceptions. I've reported these problems over the years and I usually get a "can't reproduce", or "it's a JVM issue" response. Anyways I was hoping in this forum my concerns might fall on more receptive ears.
I would like to ask if you have some measures already prepared because tomorrow is the last working day when P3 fixes can be integrated. I have noticed that Target Milestone is still set as TBD so I hope you don't plan to ignore problems of at least 3 known people. Or are we supposed to upgrade the priority to P2 on Monday ?
Adding another guy reporting this problem, Claudio Rosati. The description of his problem: I've serious memory problems with the las Q-Build (#200403040727, Win 2000, J2SE 1.4.2_03). When NB arives to consume around 200 MBytes (around 127 MBytes shown in the memory toolbar), the CPU starts to be stucked to 100%. Moreover, even closing NB, it close its main window, but the application remain up and running (and consuming memory) until I kill it in the task manager.
Created attachment 13921 [details] Zipped ide.log file from Claudio Rosati.
Claudio later mentioned that he didn't face this problem in 3.6 Beta. Another observations about memory consumption from Steven Cummings say that: "... it does seem to double after (roughly) every 2 or 3 hours."
Claudio, I see in your ide.log that you've got tons of alfa quality modules installed. Those modules are not production quality and may introduce memory leaks and other problems. First thing you should do now is to start with a fresh IDE and fresh userdir and install only those additional modules you really need, ideally not installing alfa quality modules at all. Let us know if this helps to solve the memory problems... Setting target milestone of this issue to promo-D.
There is a serious leak, no doubt. I am mainly using NB for GUI creation. Lots of custom beans and GUI components. For a while I thought that the culprit was maybe one of my beans that claims memory in a way that GC is unable to reclaim, but ... for a few days I have been trying to replicate the issue and it always works. Just use the form editor! Create a JFrame with 100 JLabels. Create another one. Open them, close them, create a new one, etc, etc. Each time you do something, memory usage goes up by 1-4 megs. Manual GC does not help. Memory usage will go up until NB is not usefull anymore. Like NB is keeping classes in some sort of cache, or not removing references to those forms/objects so GC is unable to reclaim them. I have to restart NB many times a day when I do heavy work with Form Editor.... Thanks.
Could you Mariane check this scenario if you can reproduce it ?
vanjab, thanks a lot , it seems you've find another dead-lock in our IDE, your's pointed scenario really causes 3-4 MB leak (for now I don't know where), I've filed issue 40915 against form editor ...... ... this is scenario like we are looking for .... once more THANK YOU ....
I have this problem too, using RedHat 9.0. After a while, NetBeans is stucked. I close the program and then restart it, but I can not continue to work. I have to kill the java processes or NB wouldn't work. The last time it happened I was working with XML files, XSLT performing various transformations and validating against a DTD. I think some partners in the NetCAT program had this problem of memory consuption worse when working with XML files. Is it right, Jiri?
Unfortunately no, Wendi. Only one NetCAT member (out of 24) reported poor responsiveness of editor with large XML files.
I am upgrading this to 40cat since the initial topic was the general increase in memory consumption to the point that it slows Netbeans usage to a crawl and can cause OutOfMemory errors. I have seen this problem follow the same pattern, but with varying degrees of impact on Windows 2000Pro, Linux, and Mac OSX 10.3 systems. The current state of Netbeans 4.0rc2 memory consumption follows two crippling scenarios: 1 Heap Creep 1 Netbeans opens with an initial heap limit. 2 As Netbeans is used, incremental GCs recover some, but never as much memory as a full GC, even when it sits idle. 3 Heap consumption gradually builds despite incremental GCs until the heap limit is reached. 4 A full GC is done that recovers memory the incremental GCs could not, but the heap limit is now increased. 5 Steps 2 - 4 repeat and the heap limit continues to grow, even when no operation requires that much heap. 6 As the heap limit grows, the time Netbeans spends locked up in a full GCs grows longer and longer until you're sitting there for over 10 minutes. 7 There is no way to decrease or reset the heap limit without restarting Netbeans. It will grow until Netbeans or your system crashes. 2 Virtual Page Thrash 1 Netbeans opens with an initial set of allocated virtual memory pages from the heap, taken from virtual pages possibly used by other concurrently running applications. 2 As objects are created and released, memory pages are cluttered with allocated but unused space which cannot be deallocated until the GC gets around to finalizing those objects. 3 As more objects are allocated, more virtual pages are taken from other applications. 4 Since incremental GC does not reclaim all that a full GC does, virtual pages continue to be allocated away from other applications. 5 When pages are finally cleared by the GC, they are not reused. New pages are taken for new objects. This continually cycles through the available virtual pages and constantly flushes the data of other applications. 6 Whenever focus is changed to another concurrent application, or a background task of another concurrent application is started, it must first reallocate the virtual pages it lost to the Netbeans creeping heap. 7 For Netbeans to continue it must, again, reclaim those virtual pages lost to other concurrent applications. As the heap creeps up in size, the cyclic flushing of virtual pages occurs more often, creating more lag time spent in virtual page reallocation thrash between Netbeans and the other concurrent applications. This can lock up your entire system for over 30 minutes during a full GC. The primary reason for Heap Creep is the fact that incremental GC does not eventually perform the same job as a single full GC. When Netbeans is left idle, incremental GCs should eventually bring the head down to what a single full GC does. In this way, as long as you don't actually need more memory than your current heap limit, you will not exceed that limit due to sluggish or incomplete GCs. The primary reason for Virtual Page Thrash is that Netbeans does not reuse the same set of virtual pages as do other well-behaved applications, resulting in the constant flushing of virtual page data of the other concurrently running applications. After the Netbeans heap creeps up enough, most of your processing time is spent reallocating and refreshing virtual pages between Netbeans and other applications. The same set of pages in a heap should be constantly reused as much as possible before grabbing any more from other concurrent applications. Together, these problems can make a simple 30 minute coding job in Netbeans, with concurrent File Explorer, Browser with Java documentation windows, and a Mail application, take several hours requiring several Netbeans restarts. This is an extremely serious problem that has been mentioned to the Netbeans teams in the mailing lists, and in this bug report, over and over again. In the real world there is no question that either of these problems would push a release date until they were fixed. The Target Milestone on this bug was 4.0, so it seemed appropriate to upgrade it for the 4.0rc2 release. Personally, I consider these memory problems to the the #2 priority problem with Netbeans (#1 being documentation).
Due to the age of this issue, it has been moved to #52113 at the request of the 40cat team manager Please move any votes there.
Many memory leaks were fixed since this issue was filed. Closing as fixed now. If you encounter any leaks now, please file new issues. And file each leak as a separate issue with as much information about reproduction scenario as possible.
verified/closed Our measurement shows that memory consumption of NB 5.0 doesn't increase.