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 problems with performance degradation with prolonged usage. It happens usually at the end of the day if the IDE was not restarted. There are suspicions it may coincide with exceptions when JSP editing, searching or CVS refreshing. Could you please investigate it and hopefully improve it ?
The degradation of performance leads to OutOfMemoryException. I was using a little the JSP editor, a lot CVS (with auto-refresh) and Java Editor. I was using trunk version of Netbeans yesterday and I did not experience this degradation of performance.
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) additional modules, switches, ..... Thanks for cooperation ;)
Here are the requested information : * Sun JDK 1.4.2_02 on Linux Mandrake 9.1 * I use jgoodies looks 1.2.0. * I have a Pentium 4 2.4GHz with 512 Mo RAM * I have always more or less 15 opened files (with some "big" java files > 100ko) * I'm using CVS with autorefresh when opening directory. * I'm not using cvs refresh command, and I've commited all the files with another tool. * I've disabled CVS backward compatible module. * I'm only using the module of Netbeans 3.6 beta distribution. * I was only editing files using a lot "Alt+K" and "Go to definition", "Go to declaration". * I'm using a lot Ant to compile. * I'm using jikes 1.19 as compiler. * I've kepted the flags from Netbeans 3.5.1 (i never experienced OOME with them but perhaps there is something wrong) : -J-Xms96m -J-Xmx96m -J-Xverify:none -J-XX:+UseConcMarkSweepGC -J-XX:+BackgroundCompilation -J-XX:+UseParNewGC -J-XX:+CMSParallelRemarkEnabled -J-XX:+UseAdaptiveSizePolicy -J-XX:CompileThreshold=100 -J-XX:SurvivorRatio=128 -J-XX:MaxTenuringThreshold=0 -J-XX:NewSize=4m -J-XX:MaxNewSize=4m -J-XX:PermSize=20m -ui com.jgoodies.plaf.plastic.PlasticXPLookAndFeel -J-DPlastic.defaultTheme=ExperienceBlue -J-DClearLook.mode=OFF -J-DPlastic.tabStyle=Metal -jdkhome /opt/j2sdk1.4.2_02 * I have 30 jars mounted and 15 CVS nodes, and the autocompletion * I use Code Completion with autoupdate on CVS filesystem) * I had edited some small XML files (10-20ko) * This day I did not used debugging (nor local, nor remote) * Disabled modules : - Applet, CVS Client/Command Line backward, Bundled Tomcat 5 server, Form Editor, Http Monitor, Internationalization of Form, JSP/Servlet Advanced, JSP/Servlet Breakpoint support, Naming, PVCS, Welvome Screen, VSS * Added module : - Beanigator/Javagator - PMD 0.91 - Jalopy 1b10 - Show in Explorer - Sysprops - Scripting (but not used this day) I cannot give you an explicit workflow as the troubles begins after 6 or 7 hours of work (the memory meter show 30Mo at the beginning and 92Mo at the end of the day).
I forgot to mention I'm using also anttoolbar module.
Assigning to performance component until we find a culprit of the problem.
Hi, though i have raised the above issue thru the Cat36 forum but i was unable to furnish with any hard evidence like exception stack trace etc. I also understand the difficulties in solving an "elusive" bug seems to be lurching around the corner.. :) I typically leave the IDE running as long as it could until i find that it is behaving in an unpredictable or strange manner or with degrading performance. I dont use any of the Server side technologies e.g. JSP, servlets with exception JMS clients. I do open many files at a time - more than 10. I only use the editors (Java, XML, sometimes GUI Forms) and lots of debugging with multi threaded apps and running multi session at a time. Pls note, there are times that the IDE became slow when i was only doing pure editing with no debugging session ever started. Hope this helps chung-onn
I apologize, i forgot to mention my env setup. My setup is as follows: OSX 10.3 java 1.4.2_03 NB - use all default settings and no additional modules added (in previous added only RefactorIT) 2GB ram Screen resolution 1280x1024 chung-onn
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 4 known people. Or are we supposed to upgrade the priority to P2 on Monday ?
Eric, you are partly creating your own problem here: -J-Xms96m -J-Xmx96m -J-Xverify:none -J-XX:+UseConcMarkSweepGC -J-XX:+BackgroundCompilation -J-XX:+UseParNewGC -J-XX:+CMSParallelRemarkEnabled -J-XX:+UseAdaptiveSizePolicy -J-XX:NewSize=4m -J-XX:MaxNewSize=4m You are setting the NewSize to be very, very small. That means that minor GC's will be happening constantly, and a lot more objects will end up getting tenured and hanging around until a full garbage collection happens. Further, I believe some of these switches actually contradict each other - you are telling the garbage collector to adaptively size the memory areas it uses and then specifiying fixed sizes for them. Also, on 1.4.2 in NetBeans, UseConcMarkSweepGC will be slower not faster; and its benefits on a single processor machine are limited (as with background compilation). I'd suggest turning off *all* of the exotic HotSpot switches, and see if the problem goes away. Also, to help isolate the problem, try turning off some of these - Beanigator/Javagator (okay I wrote it and I don't believe it has any memory leaks) - PMD 0.91 - Jalopy 1b10 - Show in Explorer - Sysprops - Scripting (but not used this day) All it takes is any one of these modules to have a memory leak (holding static references to nodes, etc.) to cause a slowdown, because most memory will be in use, and the JVM will be fighting to keep running using only the tiny amount of memory it has left, and garbage collecting constantly to keep enough room to do what's being asked of it. Probably INSANE ( http://performance.netbeans.org/insane/ ) could be used to track down the culprit, run with internal execution once the IDE reaches this state. But first get rid of the HotSpot settings and see if that fixes things; also you might try turning all of the additional modules off, and then one-per-day turning them back on and see when the problem happens again. Cheong, I use NetBeans daily on a very large project (NetBeans itself) on OS-X, and have never had a similar problem. The priniciple difference in our usage patterns is that I very rarely use the debugger (old System.out.println() habits never die). So perhaps the debugger is implicated here?
Tim, I've deleted all the Hotspot switches, and disabled the modules. I think you are right because I've upgraded to -J-Xmx128m two days ago and I did not experience OutOfMemoryException and no degradation of performance (Netbeans use more or less 85Mo). I will add the result in a couple of day.
Thanks Tim, your suggestions works well on latest q-build for me ! The memory consumption is at 90Mo more or less (I kept -Xmx128m flag), and I did not experience OutOfMemoryException. The jvm arguments was given on netbeans mailing list (however they were for JDK 1.4.1). Will the performance team give good java arguments as they have done with JDK 1.4.1 (http://performance.netbeans.org/reports/gc/) ?
i have been using the latest Q Build (200402251620) for a week now, it seems that the response of the debugger is much better than before, also i notice that when using the editors the memory of the IDE did not climb steadily like that of the Beta version.
The problems reported in this issue by Eric Hartmann and Cheong Chung Onn seem to be eliminated. And two major memory leaks which were found (issue 40504 and issue 40565) are now fixed. Retargeting this issue for promo-D but keeping it open as an umbrella issue. If anyone encounters a specific problem, either add a comment to this bug with as much information as possible, or even better enter a specific bug for the particular problem and link it in this bug (in the field "Issue depends on:" of this bug).
This issue has been left in the cold for 1.5 year now and I think it is rather out-dated even as an umbrella issue. Shall we close this?
With NB5's recent daily builds my record has been using it for nearly a week continuously without any performance degradations encountered. So I'll close this antiquated issue as fixed for now.
verified/clsoed
NetBeans: 5.0 RC2 (Build 200601172200) OS: Windows XP Professional (Service Pack 2) Java: 1.5.0_06 Memory: 1.5 GB NetBeans Memory Settings: netbeans_default_options="-J-Xms32m -J-Xmx192m -J-XX:PermSize=32m -J-XX:MaxPermSize=96m -J-Xverify:none -J-Dapple.laf.useScreenMenuBar=true" This issue has popped up again. I have noticed that it may occur when using a large file. I have a file (JFrame) with approximately 5100 lines and uses the form editor. If I let the system idle for over an hour or so and return. The NetBeans response is very slow making it unusable and causes me to shut down the IDE and restart it. The other applications I have running on my system have no problems with there response and I typically will have maybe 8-15 other applications up and running.
> I typically will have maybe 8-15 other applications up and running This may be the reason. Do you have all memory utilized or is there still a reasonable amount of RAM free? If you leave a Java application idle for some time, significant amount of its memory blocks may be swapped out. Does the performance degradation happen also if Netbeans is the only application running in the system? What is the utilization of Netbeans heap at the moment of performance degradation? (you can see that in Memory toolbar if you enable it via View/Toolbars/Memory)
Let's close this too general issue. Hints how to tune the IDE and provide more detailed report are linkes from attached URL. If the last problem with large form file persists it is worth separate issue.