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.
In real work, typing in editor, working with form, virtually everything is paused from time to time (approx every 5 min on my machine) and system freezes say for 4-5 seconds. I assume JVM is going through full GC cycle. http://www.netbeans.org/servlets/ReadMsg?msgId=377567&listName=nbdev
I'm using version control and the "freeze" is closer to a minute every 5-10 min. Needless to say, this is blatantly unacceptable for a professional quality app.
Hmm, but this is hardly a problem of the GC. Even for large heaps, the GC will collect it in few seconds, not a minute. Please check that the pauses are really caused by the gc, and if so, the problem is not the GC byt your heap growing out of the physical memory (Once it starts swapping the heap noone can help you). Try running the IDE with -J-verbose:gc, the JVM will show you logs like: [Full GC 6204K->5994K(24640K), 1,0923633 secs] If the time there is the minute you're writing about then your heap have probably grown out of the physical memory (How much memory do you have?) If not, the freezes have another cause, try to invoke a thread dump during the freeze (press Ctrl-\ in the spawning console on unices, Ctrl+Break on windows) and post them here.
Umbrella type of issue - will need several things to fix in various modules - adjusting priority, changing component, adding cc.
Most of the problem can be solved by using more advanced garbage collectors, like -J-XX:+UseConcMarkSweepGC. We'll probably need to better track medium-lived objects generation.
I got the same problem with the original poster. Every few minutes (when the toolbar-memory show full), the gui freeze, look like it doing gc. There is another GC weird bug. If I set the J-Xms96m J-Xmx256m, the memory usage never go above 96m, evertime it reach 96m it start gc, I check this by looking at toolbar-memory. However, if using the default H-Xms24m, the memory usage can go above 24m, but still always full gc at 96m. If I set J-Xms128 J-Xms96m J-Xmx256m, the memory usage never go above 128m. For unknown reason look like nb4-beta1 ignore Xmx flag if Xms is set above 24m. This is repeatable in my machine at least.
To kiyut: make sure you are passing the parameters correctly. In NetBeans 4 builds you need to edit etc/netbeans.conf file. Passing the parameter more than once does not make sense.
In fact I set it using [netbeans_dir]/etc/netbeans.conf Here is part of the netbeans.conf that I modify # options used by netbeans launcher by default, can be overridden by explicit # command line swiches netbeans_default_options="-J-Xms96m -J-Xmx128m -J-Dnetbeans.logger.console=true -J-ea" I also did try using command line param, but either way produce the same result in netbeans4-beta1.
What is your platform, JDK, IDE build? You can check if the params are really applied with jstat utility (http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jstat.html, see -gccapacity).
Java version: 1.4.2_04 IDE build: 4.0beta1 (build 200408191352) Platform: Linux Mandrake 10 Kernel: 2.6.3-4 additional note, if I remove Xms and only use Xmx it is work as expected, the memory could up to max specified
Reassigning to Petr. Last attempt to use CMS GC as a default GC failed due problems with stability on JDK 1.4.2 and debugger problems.
Anyway, it should not be that big problem these days thanks to good generational GC of 1.4.2 and 1.5 JDKs. CMS is still a no-go for 1.4.2_06 JDK as it crashes frequently for us.
Well - the problem does persist and rather noticable on my machine (w/ 1GB RAM). The issue as I see it is that the probability of a GC increases as a user wants to perform some tasks (e.g. opening / sharing files / projects, compiling / testing etc.), which in principle should be able to hide away via various tricks against users' perception. One thing that might worth trying is to turn on CMS or other new GC algorithms in Tiger.
Alexis: I am not sure what do you want to hide away and what tricks do you mean? Re CMS: it is likely that if we abandon 1.4 support we will switch to CMS as a default.
Is this still valid? My feeling is that these days the editor is much better.