JVM Kernel Dump Queries

Question

The JVM crashed and created a JVM kernel pid file. I am inexperienced with core JMV files, so I could use the help with the following.

The error I am getting is:

# # A fatal error has been detected by the Java Runtime Environment: # # java.lang.OutOfMemoryError: requested 32756 bytes for ChunkPool::allocate. Out of swap space? # # Internal Error (allocation.cpp:117), pid=20119, tid=797133728 # Error: ChunkPool::allocate # # JRE version: 6.0_21-b06 # Java VM: Java HotSpot(TM) Server VM (17.0-b16 mixed mode linux-x86 ) # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # And Heap memeory statistics is, Heap PSYoungGen total 248832K, used 123509K [0x89850000, 0x9efa0000, 0xb42f0000) eden space 238656K, 47% used [0x89850000,0x90701918,0x98160000) from space 10176K, 99% used [0x98ab0000,0x9949bea0,0x994a0000) to space 56448K, 0% used [0x9b880000,0x9b880000,0x9efa0000) PSOldGen total 699072K, used 404738K [0x342f0000, 0x5eda0000, 0x89850000) object space 699072K, 57% used [0x342f0000,0x4ce30870,0x5eda0000) PSPermGen total 29056K, used 28878K [0x302f0000, 0x31f50000, 0x342f0000) object space 29056K, 99% used [0x302f0000,0x31f23be8,0x31f50000) JVM arguments, VM Arguments: jvm_args: -Xms1024M -Xmx2048M -verbose:gc -XX:+HeapDumpOnOutOfMemoryError -Xss128k -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintCommandLineFlags -XX:+HeapDumpOnOutOfMemoryError --------------- SYSTEM --------------- OS:Red Hat Enterprise Linux AS release 4 (Nahant Update 6) uname:Linux 2.6.9-67.ELsmp #1 SMP Wed Nov 7 13:58:04 EST 2007 i686 libc:glibc 2.3.4 NPTL 2.3.4 rlimit: STACK 10240k, CORE infinity, NPROC 274431, NOFILE 4096, AS infinity load average:1.32 1.50 1.52 CPU:total 4 (2 cores per cpu, 1 threads per core) family 15 model 65 stepping 3, cmov, cx8, fxsr, mmx, sse, sse2, sse3, mmxext, 3dnow, 3dnowext Memory: 4k page, physical 16631944k(115380k free), swap 18940592k(18614440k free) vm_info: Java HotSpot(TM) Server VM (17.0-b16) for linux-x86 JRE (1.6.0_21-b06), built on Jun 22 2010 01:04:46 by "java_re" with gcc 3.2.1-7a (J2SE release) time: Sat Dec 24 11:09:25 2011 elapsed time: 84994 seconds 

Based on the above data from the main file,

1) With ~ 18 GB of free memory, any idea why the error is “out of swap space?”? That should not be so. Only physical memory is very low, which is only ~ 115 MB of free space.

2) Of the 16 GB of physical memory for the JVM, only 2 GB is allocated. But according to statistics, almost 16 GB is fully used, and only 115 MB is free. So another process would also take up memory. Should I check this direction?

3) Ideally, the JVM will create and process Java objects, as well as create its own objects in its own library. What memory will be used for native JVM objects. will it be distributed within the specified heap limit or will it be completely distributed outside the heap?

It will be really useful if you can answer the above question for my understanding and analysis.

Answer 1

you only have 2gb allocated for your application, so if memory goes above it, you get an OOM exception

jvm_args: -Xms1024M -Xmx2048M → This is important

Answer 2

I could not find the correct links to get more information, but the physical memory is exhausted in your case, 99% is used (object space), which causes an error. You may need to increase the heap memory allocation with the -Xmx maximum heap memory option.

Answer 3

I saw this error when virtual memory ran out. Since you have a 32 bit JVM and you are close to the limit with a bunch of 2 GB. You can use the remaining available address space with a shared library, stream stacks and direct memory and get a "Space Replace" error.

The simplest solution is to use a 64-bit JVM, which completely eliminates this problem. I would also use the Java 6 30 update, as it has a number of fixes and performance improvements.

By the way, you can simply write the following that matches -Xms1024M -Xmx2048M

 -ms1g -mx2g 

The 64-bit JVM will still use 32-bit links in the latest JVMs, so you should not see a significant increase in memory consumption.