来自JVM核心文件转储的查询

Question

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

The error which 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

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

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 details from the core file,

1) With ~18GB of swap free, any idea why the error is "Out of swap space?"? It should not be the case right. Only physical memory is very low, which is just ~115 MB of free space.

2) Out of 16 GB of physical memory, only 2 GB is allocated to JVM. But as per the stats, almost 16 GB is completely used and only 115 MB is free. So, other process also would have occupied the memory. Should I check in this direction?

3) Ideally JVM will create and handle java objects and also it has to create its own native library objects. Which memory will be used for JVM's own native objects. will it be allocated within the specified heap limit or it will be allocated completely outside the heap?

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

Answer 1

you have only 2gb allocated to your application so if the memory goes above it, you get an OOM Exception

jvm_args: -Xms1024M -Xmx2048M --> This is important

Answer 2

I couldn't find proper links to get you more information, but physical memory is exhausted in your case, 99% used (object space), which is causing error. You may need to increase heap memory allocation by max heap memory parameter -Xmx.

Answer 3

I have seen this error when you have run out of virtual memory. Since you have a 32-bit JVM and you are close to the limit with a 2 GB heap. You can use up the rest of the available address space with shared library, thread stacks and direct memory and get an Out of swap space error.

The simplest solution is to use a 64-bit JVM which avoids this issue entirely. I would also use Java 6 update 30 as it has a number of fixes and performance improvements.

BTW you can just write the follow which is the same as -Xms1024M -Xmx2048M

-ms1g -mx2g

The 64-bit JVM will still use 32-bit references in the latest JVMs so you shouldn't see a significant increase in memory consumption.