When performing different actions in MSTR, an error like this listed may be displayed:
java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: PermGen space
java.lang.OutOfMemoryError: Requested array size exceeds VM limit
java.lang.OutOfMemoryError: request <size> bytes for <reason>. Out of swap space?
java.lang.OutOfMemoryError: <reason> <stack trace> (Native method)
The principal cause of this errors is a Memory Leak in Java code. In Java, a memory leak occurs when object references that are no longer needed are unnecessarily maintained.
A memory leak is an OutOfMemoryError (OOM). But not all OOMs necessarily imply memory leaks: an OOM can occur due to the generation of many local variables or other such events. On the other hand, not all memory leaks necessarily manifest themselves as OOMs, especially in the case of desktop applications or client applications.
The OOM is a common indication of a memory leak. Essentially, the error is thrown when there’s insufficient space to allocate a new object. Thus, an error emerges, along with a stack trace. The first step in diagnosing the OOM is to determine what the error means.
Depending on the error displayed the origin an action to be followed may change.
“Java heap space” is an error message that doesn’t necessarily imply a memory leak, mostly it is a configuration issue. It is necessary to adjust the JVM’s memory parameters. We met this kind of leak on Tomcat's configuration. Another potential source of these “Java heap space” OOMs arises with the use of finalizers. If a class has a finalize method, then objects of that type do not have their space reclaimed at garbage collection time. Instead, after garbage collection, the objects are queued for finalization, which occurs later.
You can be able to modify the heap size for:
Please review the KB6446 to know more about this configuration.
“PermGen space” This error message indicates that the permanent generation is full. The permanent generation is the area of the heap that stores class and method objects. If an application loads a large number of classes, then the size of the permanent generation might need to be increased using the -XX:MaxPermSize option. Please review the KB325279 for knowing more about this configuration.
“Requested array size exceeds VM limit” This error indicates that the application attempted to allocate an array that is larger than the heap size. For example, if an application attempts to allocate an array of 512MB but the maximum heap size is 256MB, then an OOM will be thrown with this error message. In most cases, the problem is either a configuration issue or a bug that results when an application attempts to allocate a massive array.
It is possible anyway to modify the heap size in HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Strategy\JNI Bridge\Config for DataServices\32-bit JVM for Windows. And for Linux HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Strategy\JNI Bridge\Config for DataServices\64-bit JVM
“Request <size> bytes for <reason>. Out of swap space” This message appears to be an OOM. However, the HotSpot VM throws this apparent exception when an allocation from the native heap fails, and the native heap might be close to exhaustion. Included in the message are the size (in bytes) of the request that failed and the reason for the memory request. The <reason> is the name of the source module that’s reporting an allocation failure. In some cases, the problem might not even be related to the application. For example, you might see this error if:
<reason> <stack trace> (Native method) If you see this error message and the top frame of your stack trace is a native method, then that native method has encountered an allocation failure. The difference between this message and the previous is that the allocation failure was detected in a JNI or native method rather than in Java VM code.
