Question

My Application(a Desktop application) through the following exception in

java.lang.OutOfMemoryError: requested 4096000 bytes for GrET in C:\BUILD_AREA\jdk6_12\hotspot\src\share\vm\utilities\growableArray.cpp. Out of swap space?

What are the possible reasons for the above error.

Here is the jvm argument which are set

VM Arguments:

jvm_args: -Dsun.net.inetaddr.ttl=10 vfprintf exit abort -Xms5242880 -Xmx1711276032 -XX:NewSize=2621440 -XX:MaxNewSize=855638016 -XX:+HeapDumpOnOutOfMemoryError -Dsun.rmi.dgc.server.gcInterval=60000 -Dsun.rmi.dgc.client.gcInterval=60000 -Djava.security.properties=wigan.java.security -Xss512K

--------------- S Y S T E M ---------------

OS: Windows NT 6.1 Build 7601 Service Pack 1

CPU:total 24 (16 cores per cpu, 2 threads per core) family 6 model 13 stepping 7, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, ht

Memory: 4k page, physical 4194303k(4194303k free), swap 4194303k(4194303k free)

vm_info: Java HotSpot(TM) Server VM (11.2-b01) for windows-x86 JRE (1.6.0_12-b04), built on Jan 17 2009 09:52:33 by "java_re" with MS VC++ 7.1

I added -XX:+HeapDumpOnOutOfMemoryError to the jvm parameters, but it jvm didn't dump the heap, I never find any .hprof file. Why?

Is it compulsary that when ever the hs_err_pidXXXX.log file is created the hprof file also created?

Was it helpful?

Solution

When the OutOfMemoryError is accompanied by "Out of swap space?" the error occured while trying to allocate resources on a native level. In your case it seems an internal C++-procedure failed to allocate needed memory. This seems to be the reason why the heap-dump isn't created: when failing on the native level the VM's builtin error-handling might not have a chance to take over - as opposed to errors on java-level, like running out of (java-)heap-space.

By default, Windows NT user-space is 2GB, since your java heap is already 1,7GB there is not much headroom left for non-heap memory and your application seems to bump into the ceiling there.

There two things you can try to fix the error:

  • reduce your Xmx to allow for more non-heap-memory
  • try setting the /3GB boot parameter (not sure wether this is supported in your Windows-version) to reduce system-space to 1GB and so increase user-space to 3GB

OTHER TIPS

quoting Memory Analyzer wiki:

Heap dumps are not written on OutOfMemoryError for the following reasons:

  • Application creates and throws OutOfMemoryError on its own
  • Another resource like threads per process is exhausted
  • C heap is exhausted

As for the C heap, the best way to see that you won't get a heap dump is if it happens in C code (eArray.cpp in the example below):

# An unexpected error has been detected by SAP Java Virtual Machine:
# java.lang.OutOfMemoryError: requested 2048000 bytes for eArray.cpp:80: GrET*. Out of swap space or heap resource limit exceeded (check with limits or ulimit)?
# Internal Error (\\...\hotspot\src\share\vm\memory\allocation.inline.hpp, 26), pid=6000, tid=468

C heap problems may arise for different reasons, e.g. out of swap space situations, process limits exhaustion or just address space limitations, e.g. heavy fragmentation or just the depletion of it on machines with limited address space like 32 bit machines. The hs_err-file will help you with more information on this type of error. Java heap dumps wouldn't be of any help, anyways.

Also please note that a heap dump is written only on the first OutOfMemoryError. If the application chooses to catch it and continues to run, the next OutOfMemoryError will never cause a heap dump to be written!

If a .hprof is created, it would've said so at the time of the error message. Note that on windows, the file would not be on application folder but either on temp folder or Dr. Watson installation folder.

However, as "out of swap space" is explictly listed as a reason not to write a heap dump, I think this is what is happening.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top