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.
Product Version: NetBeans IDE Dev (Build 20080817165638) Java: 1.5.0_13; Java HotSpot(TM) Client VM 1.5.0_13-121 System: Mac OS X version 10.4.11 running on i386; MacRoman; en_US (nb) 1. Start NetBeans with a fresh userdir. The memory meter is at about 39 MB of used memory, and the NetBeans process in Activity Monitor has about 214 MB of real used memory 2. Do nothing for several hours - the used memory in memory meter will grow indefinitely (in my case 77 MB), as well as the size of the NetBeans process (373 MB for me) Forcing garbage collection by clicking the memory meter helps temporarily (used heap goes back), but then it starts growing again.
A few comments: -if the used memory goes back to its starting state after GC, this is not a memory leak as such - only some garbage is not collected, because the GC has a lot of memory to work in, and does not bother collecting the garbage. -the memory view toolbar itself produces little bits of garbage while repainting - this itself could (and probably does) account for the described behavior. -Is this problem really so serious that it deserves P1? Is it really (much) more serious than e.g. issue #143234 (which is P2), which speaks about leak(s) and problems during real work of a user?
I agree this may not be P1, downgrading to P2. The behavior is still really nasty though, because as the size of NetBeans process grows, it causes the other processes to swap out to disk, which then slows down the whole machine. I also don't know whether after GC, the OS frees up this memory so it is usable by other processes.
As Honza already wrote, memory meter is perhaps the reason. I tried to run empty IDE with new user dir, switched off the memory meter. Then, I minimized IDE. Thread view in visualVM does not show any "computing" activity. IMO there is no real problem with empty IDE.
Should be easy to compare IDE left for couple of hours with memory meter on and off...
I can confirm that after turning off memory meter, the problem does not appear. > IMO there is no real problem with empty IDE. Well, there is. The memory meter (which is a part of "empty IDE"), is the problem.
I am confused - we were always disabling the Memory Meter by default for releases. When this changed?
No, the memory meter is not disabled in final releases, it is only hidden by default. So the steps to reproduce in a FCS release are: 1. Right-click the empty space in the toolbar and click Memory 2. The Memory toolbar appears, and the problem can be reproduced Also, having this issue in development/beta builds is pretty nasty too, because it obscures other memory issue and makes them harder to find, and creates bad perceptions about NetBeans memory usage.
So either remove the memory meter from the IDE completly or redefine quantum mechanics. There's no measurement w/o effect. > "The behavior is still really nasty though, because as the size of NetBeans process grows, > it causes the other processes to swap out to disk, which then slows down the whole machine." This is nonsense. As with any other java application, you're giving it a playground in the terms of max heap size, which is currently computed sensibly to avoid what you're talking about. If you're so low on memory, you're already running too many apps for the machine and try to squeeze the last bit of your system. Why would you leave your IDE running in the background in such a situation. When it comes to swaping out, your idle IDE is one of the targets too and will stay mostly swapped out, up to the first major GC, where, as any other java app, it would need to page in whole java heap for a while. > "Also, having this issue in development/beta builds is pretty nasty too, because it obscures other memory issue > and makes them harder to find, and creates bad perceptions about NetBeans memory usage." Nonsense. Quite the opposite. Are you chasing memory leaks by leaving the IDE idle for few hours and then just check the memory meter? Hardly. At the most similar case, you'd press the memory/gc button first and then judge. But in reality, you'll be performing hard work in between and would have to press gc anyway. And even blinking caret in editor likely produce more short-lived (but counted) garbage than this.
I do not expect we will do anything in this area, marking as WONTFIX.