What can I do if NetBeans IDE runs out of memory (OutOfMemoryError is thrown)?
Usually there are two reasons for OutOfMemoryError in NetBeans IDE.
- Either the application really requires more memory and you need to customize it.
- Or there is a memory leak problem that needs to be fixed. These problems are often hard to fix so a good bug report is always useful to increase likelyhood that it gets fixed soon.
-J-XX:MaxPermSize(permanent generation) flags in the netbeans_default_options setting in the etc/netbeans.conf file. However, be really careful with this. NetBeans automatically sets the memory settings based on the actual physical memory of the system, which should suffice in great majority of uses. Unless you have a rather small memory and want bigger portion of it to be allocated, don't change the default memory settings. Too high numbers can actually make things even worse, e.g. due to limits of memory address space, too long running garbage collections, excessive memory-disk swapping, etc.
Note: 64-bit JVM generaly requires more memory than 32-bit so the default configuration can be too small in these cases.
Recommendations for filing bug report are summarized in How to Write a Good Bug Report page and there are few more steps that can help in this specific case.
- Writing a detailed description of how the problem can be reproduced is the best way to make it easy to analyze the problem.
- Custom modifications of netbeans.conf file should be mentioned especially if they are related to memory management.
- Information about additional modules installed into IDE can be important (attaching IDE log stored in var/log/messages.log suffices).
- Heap dumps are the best source of information for the developers in most of cases of memory leaks. Also a memory histogram can be useful; it can be easily generated via jmap tool from JDK 6. The histogram is much smaller than a heap dump and can be easily attached to issue reports.
jmap -histo:live <pid>
- Adding the PERFORMANCE keyword to a bug will attract attention to the bug.
Often it is hard to find what steps have to be performed to reproduce a leak. Some of the leaks are not massive and they are slowly degrading performance with more and more live objects on Java heap and finally resulting in an OOME. In these cases it might be useful to generate a dump of Java heap that can be used for postmortem analysis. NetBeans developers should be able to process these dumps to find what data structure is causing the problem and often this is the most important information required to fix the problem.
JVM memory dumpers
Use VisualVM to generate heap dump. Dump generation is available in context menu on your process. It is possible to switch on automatic generation of heap dump when OOME is thrown with Java SE 6 or with recent update of Java SE 5 (version 1.5.0_07 or newer) and VisualVM. Select Enable Heap Dump on OOME in process context menu. Another way of automatic heap dump when OOME occurs is adding -J-XX:+HeapDumpOnOutOfMemoryError flag into netbeans.conf file (see FaqNetbeansConf for details). Optionally this flag can be used together with -J-XX:HeapDumpPath=/path/to/dumps to specify place where these dumps will be generated. Another way how to obtain these dumps is to use jmap tool to produce dump on demand.
Trouble-Shooting and Diagnostic Guide for Java SE 5 or more recent JavaSE 6 performance documentation contains useful information about memory leaks and tools that can be used to generate a dump of memory content. Slides from BOF presentation about OutOfMemoryError from JavaONE2005
Yet another possibility to generate a memory dump is INSANE tool. It works well with Java 1.4.2 and newer and provides two ways how to generate the dump. There is a button in memory toolbar and also it is possible to provoke the dumping by starting another instance of the IDE and passing --dumpfile option to it. Unfortunately there has to be some space on Java heap to produce the expected results.
Various types of memory leaks
Java heap space. This is the most common type of this error. It often indicates problem in the code and heap dump or histogram of objects allocated on heap is useful for finding the root of problem.
The permanent generation is a special area where objects are allocated. It is used to hold reflective of the VM itself such as class objects and method objects. Usually maximum allowed size (96MB as specified by -XX:MaxPermSize option in etc/netbeans.conf file) in NetBeans should be adequate for 32-bit VM. It can be necessary to increase size of this area if 64-bit JVM is used (max size of permgen area was increased to 160MB after 5.0 release so even 64-bit VMs can be used without problems).
However sometimes it can be fully occupied too. Often a problem with classloaders that are not released from memory and too many classes are loaded into one instance of JVM. It can be caused for example by Ant tasks that can be working properly if every run is executed as a new process but may fail if they are executed more times within the same JVM. Frequent module enabling and disabling (installing and uninstalling) can also cause this. Approaches on how to fix "java.lang.OutOfMemoryError: PermGen space" exception include looking for orphaned classloaders and classloaders with the same sets of classes. (More information on the dreaded "java.lang.OutOfMemoryError: PermGen space" exception and JavaOne2007 conference slides).
Processing of outputs in IDE (for example during compilation or process execution) uses mapping of memory regions to allow displaying of large outputs. Some OOME were reported there with older releases of NetBeans or with older versions of Apple's JVM.
Applies to: NetBeans 4.0 and newer