Tuning JVM switches for performance
JVMs offer a variety of standard and non-standard switches that tune memory allocation and garbage collection behavior. Some of these settings can benefit NetBeans' performance.
Note that -X and especially -XX JVM switches are officially "unsupported" -
they are often JVM or JVM-vendor specific. The switches discussed on this page are
available on Sun Microsystems J2SE 1.5.0 - users of other JVM implementations may
need to remove these switches in order to run NetBeans. For example, if you want to run the IDE on IBM JDK, you have to remove
–J-XX:MaxPermSize=96m from the configuration file
The documentation of Sun's JDK 5 and newer refers to Trouble-Shooting and Diagnostic Guide containing many tips how to find problems that are often related to performance.
How to specify JVM switches
Java switches are passed on the command line that starts the JVM, for example, by typing
java -jar -Xmx96M someJar.jar. Since NetBeans is started by a launcher program rather than by calling
javadirectly, the NetBeans launcher looks for these settings in a special file called
etcdirectory of IDE instalation. Alternatively, arguments can be passed to the java process on the command line by prepending
For example, to set the
-Xmx (maximum heap size) for the JVM
NetBeans will run in, edit the file called
netbeans.conf in the
$NB_HOME/etc directory, and include the option
or launch the ide by typing
or, on Windows systems
netbeans.conf file can have the various JVM switches included
in the text string assigned to
netbeans_default_options variable. Note that the Sun
JVM does not start when passed line switches it doesn't understand,
but it will return a message pointing out what the problem was,
Unrecognized option: -foo
Could not create the Java virtual machine.
Generally useful switches
The following settings should produce better-than-factory setting performance on most systems. With the exception of setting the "permanent area" size, these switches have been the defaults for NetBeans for some time, and should already be in your
- -J-Xms32m - this setting tells the Java virtual machine to set its initial heap size to 32 megabytes. By telling the JVM how much memory it should initially allocate for the heap, we save it growing the heap as NetBeans consumes more memory. This switch improves startup time. It is used by default in NetBeans, so you do not need to specify it.
- -J-Xmx256m - this settings tells the Java virtual machine the maximum amount of memory it should use for the heap. Placing a hard upper limit on this number means that the Java process cannot consume more memory than physical RAM available. This limit can be raised on systems with more memory. Current default value is 128MB. Note: Do not set this value to near or greater than the amount of physical RAM in your system or it will cause severe swapping during runtime.
More exotic switches
Listed below are some additional JVM switches which have either anecdotally or measurably impacted NetBeans performance on some, not all, systems. Your mileage may vary, but they may be worth a try.
or -J-XX:+UseParNewGC - try these switches if you are having
problems with intrusive garbage collection pauses. This switch causes the
JVM to use different algorithms for major garbage collection events (also
for minor collections, if run on a multiprocessor workstation), ones
which do not "stop the world" for the entire garbage collection
process. You should also add the
line -J-XX:+CMSClassUnloadingEnabled and
netbeans.conffile so that class unloading is enabled (it isn't by default when using this collector).
- -XX:+UseAdaptiveSizePolicy - this switch may help improve garbage collector throughput and memory footprint. It is part of garbage collector ergonomics implemented in JDK5.0.
- -J-XX:+UseParallelGC - some tests have shown that, at least on
systems fairly well equipped with memory, the durations of minor garbage
collections is halved when using this collection algorithm, on uniprocessor
systems. Note that this is paradoxical - this collector is designed
to work best on multiprocessor systems with gigabyte heaps. No data is
available on its effect on major garbage collections. Note:
this collector is mutually exclusive with
-J-XX:+UseConcMarkSweepGC. . The measurements supporting the use of this algorithm can be found on the performance website.
- -J-XX:+PrintGCDetails - this is similar switches (like -J-verbose:gc) do not improve performance but provide diagnostic data showing information about memory management that are useful source of input for performance tuning. Another way how to obtain these data is to use monitoring tools or (NetBeans) profiler.
- -J-XX:CompileThreshold=100 - this switch will make startup time slower, by HotSpot to compile many more methods down to native code sooner than it otherwise would. The reported result is snappier performance once the IDE is running, since more of the UI code will be compiled rather than interpreted. This value represents the number of times a method must be called before it will be compiled.
- -J-Djava.net.preferIPv4Stack=true - this switch will suppress use of IPv6 stack in networking code and it can avoid small delay during startup when inet address is being resolved. It will be usefull only on a system where IPv6 is installed but not actually configured. Note: there can be another problems related to IPv6 - see for example discussion on interaction between fwbuilder and Java apps
Options affecting graphic behavior
This document contains only a small subset of switches available. More detailed description about properties affecting Java 2D(TM) behavior can be found in System Properties for Java 2D(TM) Technology document.
- -Dsun.java2d.opengl=true - enables a new OpenGL-based pipeline for Java 2D used to support hardware-accelerated rendering using OpenGL. More details about this new JDK5.0 feature are in Java 2D(TM) Technology documentation.
- -Dsun.java2d.d3d=false -
this switch disables DirectDraw and may solve performance problems with some HW configurations.
- -Dawt.nativeDoubleBuffering=true -
this switch makes Swing
assume the OS is handling double buffering and it shouldn't do
any. This will probably not work over a remote X connection,
but for local use it's very useful because you literally see every
repaint get done, and it makes it very easy to notice if some
operation is causing gratuitous repaints.
- Font anti-aliasing for Swing widgets can be turned on with -Dswing.aatext=true property. It can be useful to use together with the setting and exporting of the environment variable J2D_PIXMAPS=shared at least on Linux platform to obtain reasonable performance (this is now done by default in the launcher (platform5/lib/nbexec) so you do not need to set it).