This question already has an answer here:
Why does a JVM report more committed memory than the linux process resident set size?
(1 answer)
Closed 3 years ago.
I have a JVM which reports committed heap memory as around 8GB (Other sections should be over and above this). But my OS shows memory usage as around 5GB. I understand the memory usage can be more than the committed memory due to non-heap, metaspace etc, but how is it possible that the usage is lesser than reported by the jvm?
The output of free shows memory usage of 5.5GB
#free -m
total used free shared buff/cache available
Mem: 24115 5536 16355 10 2223 18209
Swap: 0 0 0
Output of Native Memory Tracker (NMT) shows reserved memory as ~ 11 GB
#jcmd <pid> VM.native_memory
Total: reserved=12904933KB, committed=11679661KB
- Java Heap (reserved=8388608KB, committed=8388608KB)
(mmap: reserved=8388608KB, committed=8388608KB)
- Class (reserved=1161913KB, committed=127417KB)
(classes #20704)
(malloc=2745KB #33662)
(mmap: reserved=1159168KB, committed=124672KB)
- Thread (reserved=2585224KB, committed=2585224KB)
(thread #2505)
(stack: reserved=2574004KB, committed=2574004KB)
(malloc=8286KB #12532)
(arena=2934KB #5004)
- Code (reserved=264623KB, committed=90231KB)
(malloc=15023KB #22507)
(mmap: reserved=249600KB, committed=75208KB)
- GC (reserved=378096KB, committed=378096KB)
(malloc=34032KB #45794)
(mmap: reserved=344064KB, committed=344064KB)
- Compiler (reserved=776KB, committed=776KB)
(malloc=645KB #1914)
(arena=131KB #7)
- Internal (reserved=53892KB, committed=53892KB)
(malloc=53860KB #67113)
(mmap: reserved=32KB, committed=32KB)
- Symbol (reserved=26569KB, committed=26569KB)
(malloc=22406KB #204673)
(arena=4163KB #1)
- Native Memory Tracking (reserved=6756KB, committed=6756KB)
(malloc=494KB #6248)
(tracking overhead=6262KB)
- Arena Chunk (reserved=11636KB, committed=11636KB)
(malloc=11636KB)
- Tracing (reserved=10456KB, committed=10456KB)
(malloc=10456KB #787)
- Unknown (reserved=16384KB, committed=0KB)
(mmap: reserved=16384KB, committed=0KB)
OS - Debian 9
Java -
java version "1.8.0_172"
Java(TM) SE Runtime Environment (build 1.8.0_172-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.172-b11, mixed mode)
I have read through some awesome answers like this one which explains NMT very well, but it doesn't address this issue. I would like to understand how this is possible.
Duplicate of Why does a JVM report more committed memory than the linux process resident set size?
This pertains to the difference between Reserved / Committed / Resident memory as explained in the above answer.
Closing this question.
While running java application I'm getting the following memory dump.
After installing java 8(with java 7 application was working before) I started getting the below error.
I'm using 16 GB RAM and in task manager when I checked (while application was starting)around 6 GB RAM was free.
Could some one please help what could be the issue?
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 472736 bytes for Chunk::new
# Possible reasons:
# The system is out of physical RAM or swap space
# In 32 bit mode, the process size limit was hit
# Possible solutions:
# Reduce memory load on the system
# Increase physical memory or swap space
# Check if swap backing store is full
# Use 64 bit Java on a 64 bit OS
# Decrease Java heap size (-Xmx/-Xms)
# Decrease number of Java threads
# Decrease Java thread stack sizes (-Xss)
# Set larger code cache with -XX:ReservedCodeCacheSize=
# This output file may be truncated or incomplete.
#
# Out of Memory Error (allocation.cpp:390), pid=1104, tid=0x00000000000016ec
#
# JRE version: Java(TM) SE Runtime Environment (8.0_92-b14) (build 1.8.0_92-b14)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.92-b14 mixed mode windows-amd64 compressed oops)
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
--------------- T H R E A D ---------------
---------------------------------------------------
Java Threads: ( => current thread )
0x00000000232a8800 JavaThread "AWSessionMonitor Thread" daemon [_thread_blocked, id=14084, stack(0x0000000022b20000,0x0000000022c20000)]
0x0000000028728800 JavaThread "Thread-3" [_thread_blocked, id=11332, stack(0x00000000210b0000,0x00000000211b0000)]
0x00000000252a4800 JavaThread "Thread-2" [_thread_blocked, id=5272, stack(0x0000000020fb0000,0x00000000210b0000)]
0x000000001e874000 JavaThread "SQLStatementMonitor" [_thread_blocked, id=1876, stack(0x0000000022620000,0x0000000022720000)]
0x000000001de0d800 JavaThread "Thread-1" daemon [_thread_blocked, id=13052, stack(0x0000000022520000,0x0000000022620000)]
0x000000001f7f8000 JavaThread "Session Timeout Thread" daemon [_thread_blocked, id=11088, stack(0x0000000022220000,0x0000000022320000)]
0x0000000002c11800 JavaThread "DestroyJavaVM" [_thread_blocked, id=14168, stack(0x0000000002a00000,0x0000000002b00000)]
0x000000001f32b800 JavaThread "Thread-0" [_thread_in_vm, id=10720, stack(0x0000000020bc0000,0x0000000020cc0000)]
0x000000001fb3e800 JavaThread "Perf_Log_Traceplan-" daemon [_thread_blocked, id=2992, stack(0x0000000020ac0000,0x0000000020bc0000)]
0x0000000020319800 JavaThread "Perf_Log_Traceperf-" daemon [_thread_blocked, id=6176, stack(0x00000000209c0000,0x0000000020ac0000)]
0x000000001da8b000 JavaThread "Service Thread" daemon [_thread_blocked, id=9968, stack(0x000000001e020000,0x000000001e120000)]
0x000000001da64000 JavaThread "C1 CompilerThread2" daemon [_thread_blocked, id=12708, stack(0x000000001df20000,0x000000001e020000)]
0x000000001c13e000 JavaThread "C2 CompilerThread1" daemon [_thread_blocked, id=10652, stack(0x000000001de20000,0x000000001df20000)]
=>0x000000001c128000 JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=5868, stack(0x000000001d920000,0x000000001da20000)]
0x000000001c118000 JavaThread "JDWP Event Helper Thread" daemon [_thread_blocked, id=12444, stack(0x000000001d820000,0x000000001d920000)]
0x000000001c10c000 JavaThread "JDWP Transport Listener: dt_socket" daemon [_thread_in_native, id=2640, stack(0x000000001d720000,0x000000001d820000)]
0x000000001c100800 JavaThread "Attach Listener" daemon [_thread_blocked, id=9952, stack(0x000000001d620000,0x000000001d720000)]
0x000000001c0ff800 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=13880, stack(0x000000001d520000,0x000000001d620000)]
0x000000001c0e6000 JavaThread "Finalizer" daemon [_thread_blocked, id=7868, stack(0x000000001d340000,0x000000001d440000)]
0x000000001c0bd000 JavaThread "Reference Handler" daemon [_thread_blocked, id=11580, stack(0x000000001d240000,0x000000001d340000)]
Other Threads:
0x000000001c0b3800 VMThread [stack: 0x000000001d140000,0x000000001d240000] [id=12984]
0x000000001db42800 WatcherThread [stack: 0x000000001e120000,0x000000001e220000] [id=9136]
VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None
Heap:
PSYoungGen total 524800K, used 42318K [0x000000076c580000, 0x000000078cf80000, 0x00000007c0000000)
eden space 515584K, 8% used [0x000000076c580000,0x000000076eed3b10,0x000000078bd00000)
from space 9216K, 0% used [0x000000078bd00000,0x000000078bd00000,0x000000078c600000)
to space 8704K, 0% used [0x000000078c600000,0x000000078c600000,0x000000078ce80000)
ParOldGen total 99328K, used 24647K [0x00000006c5000000, 0x00000006cb100000, 0x000000076c580000)
object space 99328K, 24% used [0x00000006c5000000,0x00000006c6811d80,0x00000006cb100000)
Metaspace used 22833K, capacity 23012K, committed 23344K, reserved 1071104K
class space used 2715K, capacity 2786K, committed 2864K, reserved 1048576K
Card table byte_map: [0x00000000120c0000,0x00000000128a0000] byte_map_base: 0x000000000ea98000
Marking Bits: (ParMarkBitMap*) 0x0000000069bf64f0
Begin Bits: [0x00000000131e0000, 0x00000000170a0000)
End Bits: [0x00000000170a0000, 0x000000001af60000)
Polling page: 0x00000000024b0000
CodeCache: size=245760Kb used=11544Kb max_used=11559Kb free=234215Kb
bounds [0x0000000002d00000, 0x0000000003860000, 0x0000000011d00000]
total_blobs=2659 nmethods=2233 adapters=346
compilation: enabled
Compilation events (10 events):
Event: 191.393 Thread 0x000000001da64000 2532 3 org.apache.xerces.util.XMLAttributesImpl::checkDuplicatesNS (278 bytes)
Event: 191.393 Thread 0x000000001c13e000 2535 4 org.apache.xerces.impl.XMLEntityScanner::scanQName (510 bytes)
Event: 191.394 Thread 0x000000001da64000 nmethod 2532 0x0000000003825d10 code [0x0000000003825f60, 0x0000000003826d38]
Event: 191.394 Thread 0x000000001da64000 2530 3 org.apache.xerces.impl.xs.opti.SchemaDOM::emptyElement (23 bytes)
Event: 191.394 Thread 0x000000001da64000 nmethod 2530 0x00000000037d66d0 code [0x00000000037d6840, 0x00000000037d6a98]
Event: 191.394 Thread 0x000000001da64000 2533 3 org.apache.xerces.impl.xs.opti.SchemaDOM::startElement (29 bytes)
Event: 191.395 Thread 0x000000001da64000 nmethod 2533 0x00000000037fb4d0 code [0x00000000037fb640, 0x00000000037fb8b8]
Event: 191.395 Thread 0x000000001da64000 2534 3 org.apache.xerces.impl.xs.opti.SchemaDOM::endElement (30 bytes)
Event: 191.395 Thread 0x000000001da64000 nmethod 2534 0x0000000003825750 code [0x00000000038258c0, 0x0000000003825b90]
Event: 191.423 Thread 0x000000001c13e000 nmethod 2535 0x000000000384fe10 code [0x0000000003850000, 0x0000000003850fe0]
--------------- S Y S T E M ---------------
OS: Windows 8.1 , 64 bit Build 9600 (6.3.9600.17415)
CPU:total 4 (2 cores per cpu, 2 threads per core) family 6 model 58 stepping 9, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, avx, aes, clmul, erms, ht, tsc, tscinvbit, tscinv
Memory: 4k page, physical 16442864k(1810952k free), swap 19025808k(6260k free)
vm_info: Java HotSpot(TM) 64-Bit Server VM (25.92-b14) for windows-amd64 JRE (1.8.0_92-b14), built on Mar 31 2016 21:03:04 by "java_re" with MS VC++ 10.0 (VS2010)
time: Mon May 23 12:38:20 2016
elapsed time: 191 seconds (0d 0h 3m 11s)
I was getting the similar memory dumps while running the same java application on Windows 10 and 8.1(both 64 bit).
Windows 8.1
32GB RAM
i7-4790 3.60GHz CPU
Paging file size(fixed, 14GB)
Windows 10
16GB RAM
i7-4790 3.60GHz CPU
Paging file size(automatically managed, initially was fixed, 14GB)
1st issue was that with identical hardware(the difference in RAM only and OS), application on Windwos 10 was crashing almost instantly.
The most surprising thing, that in Task manager I saw that only 25% of RAM is used.
After searching info in google, I've found that:
I need to set automatically managed paging file for Windows 10.
Windows 10 is more greedy with committed memory than previous versions of windows.
2nd issue
As was mentioned by #borjab
Java, by default, does not uses all available memory.
To get a help on non-standard options for Java type in your CMD:
java -X
Output:
-Xms<size> set initial Java heap size
-Xmx<size> set maximum Java heap size
<size> can be defined in
G - Gigabytes
M - Megabytes
K - Kilobytes
The final solution for both OS was:
java -Xmx15G -Xms15G -jar selenium-server-standalone-3.4.0.jar
My initial java version
java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)
Updated java version
java version "1.8.0_152"
Java(TM) SE Runtime Environment (build 1.8.0_152-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.152-b16, mixed mode)
Java, by default, does not uses all avalaible memory. You need to run the application with the corresponding parameters.
See this question to all the details. (It can change with the version of Java).
The parameter setting can be set on the command line but if you use an application you may have some configuration file. For example, in Eclipse you have eclipse.ini where you an set your memory preferences.
Your application, by default, does not use all the available system memory (or RAM). The limit depends on the xmx value you have set.
Not sure if 64 bit is an option for you, if it is, this lets you increase your xmx more than the 32 bit version.
Some programs use a lot of memory, like Elasticsearch, try to add more memory if you use this kind of memory intensive program
I just want to
run ORACLE SQL Developer 4.0.2.12.21
in OpenSuSE 13.11.10 - 64x
linux-l4i7:/home/suse/bin/sqldeveloper # ./sqldeveloper.sh
> Oracle SQL Developer
> Copyright (c) 1997, 2014, Oracle and/or its affiliates. All rights reserved.
>
>
>
> LOAD TIME : 448#
># A fatal error has been detected by the Java Runtime Environment:
>
># SIGSEGV (0xb) at pc=0x00007f084ebe7250, pid=20064, tid=139674518972160
>#
># JRE version: Java(TM) SE Runtime Environment (7.0_60-b19) (build 1.7.0_60-b19)
># Java VM: Java HotSpot(TM) 64-Bit Server VM (24.60-b09 mixed mode linux-amd64 compressed >oops)
># Problematic frame:
># C 0x00007f084ebe7250
>#
># Failed to write core dump. Core dumps have been disabled. To enable core dumping, try >"ulimit -c unlimited" before starting Java again
>#
>># An error report file with more information is saved as:
># /home/suse/bin/sqldeveloper/sqldeveloper/bin/hs_err_pid20064.log
>#
># If you would like to submit a bug report, please visit:
># http://bugreport.sun.com/bugreport/crash.jsp
>#
>/home/suse/bin/sqldeveloper/sqldeveloper/bin/../../ide/bin/launcher.sh: line 1193: 20064 >Aborted ${JAVA} "${APP_VM_OPTS[#]}" ${APP_ENV_VARS} -classpath >${APP_CLASSPATH} ${APP_MAIN_CLASS} "${APP_APP_OPTS[#]}"
--------------- T H R E A D ---------------
Current thread is native thread
siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x00007f084ebe7250
Registers:
RAX=0x0000000000000001, RBX=0x00007f0882166a38, RCX=0x00007f0882166700, RDX=0x00007f084ebe7250
RSP=0x00007f0882165f18, RBP=0x00007f08ba697308, RSI=0x0000000000000001, RDI=0x00007f0865061140
R8 =0x00007f08b42af7f0, R9 =0x0000000000000001, R10=0x0000000000000000, R11=0x0000000000000246
R12=0x0000000000000000, R13=0x00007f08ba6972e8, R14=0x0000000000000004, R15=0x000000000000001e
RIP=0x00007f084ebe7250, EFLAGS=0x0000000000010206, CSGSFS=0x0000000000000033, ERR=0x0000000000000014
TRAPNO=0x000000000000000e
Top of Stack: (sp=0x00007f0882165f18)
0x00007f0882165f18: 00007f08ba485e92 00007f0882166700
0x00007f0882165f28: 00007f0882166700 0000000000000000
0x00007f0882165f38: 0000000000000000 00007f08ba8bc000
0x00007f0882165f48: 00007f08ba891df0 00007f0882166700
Instructions: (pc=0x00007f084ebe7250)
0x00007f084ebe7230:
[error occurred during error reporting (printing registers, top of stack, instructions near pc), id 0xb]
Register to memory mapping:
RAX=0x0000000000000001 is an unknown value
RBX=0x00007f0882166a38 is an unknown value
RCX=0x00007f0882166700 is an unknown value
RDX=0x00007f084ebe7250 is an unknown value
Card table byte_map: [0x00007f08b8010000,0x00007f08b8221000] byte_map_base: 0x00007f08b7a20000
Polling page: 0x00007f08ba8b9000
Code Cache [0x00007f08b1000000, 0x00007f08b1470000, 0x00007f08b4000000)
total_blobs=1875 nmethods=1189 adapters=639 free_code_cache=44718Kb largest_free_block=45718336
Compilation events (10 events):
Event: 13.402 Thread 0x00007f08b409f000 nmethod 1371 0x00007f08b1421390 code [0x00007f08b14214c0, 0x00007f08b1421538]
Event: 13.402 Thread 0x00007f08b409f000 1372 java.util.Date::getTime (5 bytes)
Event: 13.402 Thread 0x00007f08b409f000 nmethod 1372 0x00007f08b1421150 code [0x00007f08b1421280, 0x00007f08b14212f8]
Event: 13.403 Thread 0x00007f08b409f000 1373 org.openide.util.NbCollections$4$1::hasNext (13 bytes)
Event: 13.403 Thread 0x00007f08b409f000 nmethod 1373 0x00007f08b1406f50 code [0x00007f08b14070a0, 0x00007f08b1407178]
Event: 13.404 Thread 0x00007f08b409f000 1374 javax.ide.extension.spi.DefaultElementContext::getVisitorForStartElementImpl (243 bytes)
Event: 13.542 Thread 0x00007f08b409f000 nmethod 1374 0x00007f08b1454e50 code [0x00007f08b1455180, 0x00007f08b1456b40]
Event: 13.542 Thread 0x00007f08b409f000 1375 oracle.javatools.data.ChangeBuffer::addChangeInfo (10 bytes)
Event: 13.546 Thread 0x00007f08b409f000 nmethod 1375 0x00007f08b1343710 code [0x00007f08b1343880, 0x00007f08b1343ba8]
Event: 13.546 Thread 0x00007f08b409f000 1376 oracle.javatools.data.ChangeInfo::<init> (85 bytes)
This is a native Java crash. It can be a Bug in the JVM, the netbeans launcher, maybe some incompatibilities in your environment (especially wrong or missing libraries).
Did this sqldeveloper installation include a JRE? You might want to change the script to point to a system JVM. The hs_err file looks a bit incomplete. It should for example contain a list of loaded libraries and the path of the actual Java binary. Did you cut that out or is it missing?
Might not be related but this worked for me
gksudo gedit /usr/bin/sqldeveloper
Then these 2 lines at the top:
unset GNOME_DESKTOP_SESSION_ID
unset DBUS_SESSION_BUS_ADDRESS
Found the answer here
http://linuxsagas.digitaleagle.net/2014/01/28/fixing-sql-developer-4-0/
We are facing the below problem at our production enviournment in unpredictable manner
sometimes the server is down in a day or sometimes in a week, below is the exact error
dump, below are the settings for the server.
JDK: jdk1.6.0_21
Server: Tomcat 7.0.2
OS: Red Hat Enterprise Linux Server release 5.5
In catalina.sh the following setting has been done:
JAVA_OPTS="-Xms1024M -Xmx1536M -XX:+HeapDumpOnOutOfMemoryError -XX:+AggressiveOpts
-XX:-DisableExplicitGC -XX:AdaptiveSizeThroughPutPolicy=0
-XX:+UsePSAdaptiveSurvivorSizePolicy
-XX:+UseAdaptiveGenerationSizePolicyAtMinorCollection
-XX:+UseAdaptiveGenerationSizePolicyAtMajorCollection -XX:PermSize=768M
-XX:MaxPermSize=768M -XX:+PrintGCDetails -Xloggc:/tmp/gcLogs.txt"
export CATALINA_OPTS="-Dcom.sun.management.jmxremote.port=22222
-Dcom.sun.management.jmxremote.authenticate=true -Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.password.file=/jakarta-tomcat7/apache-tomcat-7.0.2/conf
/jmxremote.password -Dcom.sun.management.jmxremote.access.file=/jakarta-tomcat7/apache-
tomcat-7.0.2/conf/jmxremote.access"
Error Trace:-
#
# A fatal error has been detected by the Java Runtime Environment:
#
# java.lang.OutOfMemoryError: requested 1958536 bytes for Chunk::new. Out of swap space?
#
# Internal Error (allocation.cpp:215), pid=18658, tid=589781904
# Error: Chunk::new
#
# 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
#
--------------- T H R E A D ---------------
Current thread (0x23787400): JavaThread "CompilerThread0" daemon [_thread_in_native, id=18668, stack(0x231f5000,0x23276000)]
Stack: [0x231f5000,0x23276000], sp=0x23272e70, free space=1f723276000k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x6a9262]
V [libjvm.so+0x2b277f]
V [libjvm.so+0x12e03c]
V [libjvm.so+0x12e536]
V [libjvm.so+0x5d67d0]
V [libjvm.so+0x2f809d]
V [libjvm.so+0x4f65a9]
V [libjvm.so+0x27b85f]
V [libjvm.so+0x278043]
V [libjvm.so+0x209767]
V [libjvm.so+0x280f8c]
V [libjvm.so+0x280839]
V [libjvm.so+0x66feb6]
V [libjvm.so+0x66959e]
V [libjvm.so+0x57a89e]
C [libpthread.so.0+0x5832]
Current CompileTask:
C2:3230 ! org.apache.jsp.com.common.press_jsp._jspService(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)V (4433 bytes)
--------------- P R O C E S S ---------------
Java Threads: ( => current thread )
0x09a21400 JavaThread "http-8080-exec-904" daemon [_thread_in_native, id=17126, stack(SIGTERM: [libjvm.so+0x57aaf0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGQUIT: [libjvm.so+0x57aaf0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
--------------- S Y S T E M ---------------
OS:Red Hat Enterprise Linux Server release 5.5 (Tikanga)
uname:Linux 2.6.18-194.17.1.el5PAE #1 SMP Mon Sep 20 07:34:07 EDT 2010 i686
libc:glibc 2.5 NPTL 2.5
rlimit: STACK 10240k, CORE 0k, NPROC 114688, NOFILE 1024, AS infinity
load average:0.39 0.54 0.38
CPU:total 2 (2 cores per cpu, 1 threads per core) family 6 model 15 stepping 11, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3
Memory: 4k page, physical 6228576k(225096k free), swap 6974456k(6974352k 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: Fri Dec 10 14:01:06 2010
elapsed time: 79552 seconds
Thanks in advance,
Amit
For the record (and Google), this looks like both these bugs, which were fixed in the 1.6u22 release of sun's jdk. So, first thing to do is update your JVM. If it still happens, and always happens on a particular method, you can exclude that method from compilation (as long as you're aware of the performance implications of that) with the following jvm flag:
-XX:CompileCommand=exclude,org/apache/velocity/runtime/directive/Foreach,render
(as suggested here). But, first update your jvm.
You're running with a lot of JVM args that affect memory. Have you tried empirically removing each option to see which one is causing the OOM? This particular OOM is not coming from the Java heap, it's coming from the JVM's own C heap.
As stated by the other answers / comments, you are running out of memory. Given your JVM settings, I'd say that the root cause is 99% likely to be a memory leak.
If you have been doing a lot of hot loading in the Tomcat instance, this could just be caused by that. Hot loading is notorious for leaking memory, and there is not much you can do about it in practice ... except exit and restart your Tomcat more often.
The other possibility is that your application is leaking memory. If this is the case then you will need to use a memory profiler to track down the leak.
The fact that the OOME caused a JVM crash is interesting, but probably not significant. (It looks like the JVM was trying to JIT compile a class generated from a JSP when it ran out of memory. The chunk being requested is rather large, but that probably means you have a rather large / complicated JSP.)