<p dir="ltr">Yes, swap and overcommit are turned off.  But, there's substantial free physical memory available and looks like 65kb available to expand the code heap contiguoisly.  So I'm a bit puzzled ...</p>
<p dir="ltr">Taking Chris' suggestion and cc'ing hotspot dev ...</p>
<p dir="ltr">Sent from my phone</p>
<div class="gmail_quote">On May 29, 2014 8:47 PM, "Vladimir Kozlov" <<a href="mailto:vladimir.kozlov@oracle.com">vladimir.kozlov@oracle.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Could be because there is no swap on this machine:<br>
<br>
Memory: 4k page, physical 49521668k(5596796k free), swap 0k(0k free)<br>
<br>
Vladimir<br>
<br>
On 5/29/14 5:35 PM, Christian Thalinger wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Although it’s the code cache I assume runtime folk would know more about<br>
this.  Maybe send to hotspot-dev.<br>
<br>
On May 29, 2014, at 9:01 AM, Vitaly Davidovich <<a href="mailto:vitalyd@gmail.com" target="_blank">vitalyd@gmail.com</a><br>
<mailto:<a href="mailto:vitalyd@gmail.com" target="_blank">vitalyd@gmail.com</a>>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi guys,<br>
<br>
Need a bit of help explaining a hotspot malloc failure crash on 7u51.<br>
 I'm going to paste the relevant snippets from the hs_err log.<br>
<br>
#<br>
# There is insufficient memory for the Java Runtime Environment to<br>
continue.<br>
# Native memory allocation (malloc) failed to allocate 65536 bytes for<br>
committing reserved memory.<br>
# Possible reasons:<br>
#   The system is out of physical RAM or swap space<br>
#   In 32 bit mode, the process size limit was hit<br>
# Possible solutions:<br>
#   Reduce memory load on the system<br>
#   Increase physical memory or swap space<br>
#   Check if swap backing store is full<br>
#   Use 64 bit Java on a 64 bit OS<br>
#   Decrease Java heap size (-Xmx/-Xms)<br>
#   Decrease number of Java threads<br>
#   Decrease Java thread stack sizes (-Xss)<br>
#   Set larger code cache with -XX:ReservedCodeCacheSize=<br>
# This output file may be truncated or incomplete.<br>
#<br>
#  Out of Memory Error (os_linux.cpp:2726), pid=10643, tid=47319048501520<br>
#<br>
# JRE version: Java(TM) SE Runtime Environment (7.0_51-b13) (build<br>
1.7.0_51-b13)<br>
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.51-b03 mixed mode<br>
linux-amd64 compressed oops)<br>
<br>
<br>
---------------  T H R E A D  ---------------<br>
<br>
Current thread (0x0000000000716800):  JavaThread "C2 CompilerThread0"<br>
daemon [_thread_in_vm, id=10689,<br>
stack(0x00002b095303b000,<u></u>0x00002b095313c000)]<br>
<br>
Stack: [0x00002b095303b000,<u></u>0x00002b095313c000],<br>
 sp=0x00002b0953138d20,  free space=1015k<br>
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,<br>
C=native code)<br>
V  [libjvm.so+0x992f4a]  VMError::report_and_die()+<u></u>0x2ea<br>
V  [libjvm.so+0x4931ab]  report_vm_out_of_memory(char const*, int,<br>
unsigned long, char const*)+0x9b<br>
V  [libjvm.so+0x81338e]  os::Linux::commit_memory_impl(<u></u>char*, unsigned<br>
long, bool)+0xfe<br>
V  [libjvm.so+0x81383f]  os::Linux::commit_memory_impl(<u></u>char*, unsigned<br>
long, unsigned long, bool)+0x4f<br>
V  [libjvm.so+0x813a2c]  os::pd_commit_memory(char*, unsigned long,<br>
unsigned long, bool)+0xc<br>
V  [libjvm.so+0x80daea]  os::commit_memory(char*, unsigned long,<br>
unsigned long, bool)+0x2a<br>
V  [libjvm.so+0x98e849]  VirtualSpace::expand_by(<u></u>unsigned long,<br>
bool)+0x1c9<br>
V  [libjvm.so+0x58a62c]  CodeHeap::expand_by(unsigned long)+0x8c<br>
V  [libjvm.so+0x42111d]  CodeCache::allocate(int)+0x4d<br>
V  [libjvm.so+0x7e1a39]  nmethod::new_nmethod(<u></u>methodHandle, int, int,<br>
CodeOffsets*, int, DebugInformationRecorder*, Dependencies*,<br>
CodeBuffer*, int, OopMapSet*, ExceptionHandlerTable*,<br>
ImplicitExceptionTable*, AbstractCompiler*, int)+0x179<br>
V  [libjvm.so+0x3cfc54]  ciEnv::register_method(<u></u>ciMethod*, int,<br>
CodeOffsets*, int, CodeBuffer*, int, OopMapSet*,<br>
ExceptionHandlerTable*, ImplicitExceptionTable*, AbstractCompiler*,<br>
int, bool, bool)+0x364<br>
V  [libjvm.so+0x4458fb]  Compile::Compile(ciEnv*, C2Compiler*,<br>
ciMethod*, int, bool, bool)+0x11cb<br>
V  [libjvm.so+0x3afa76]  C2Compiler::compile_method(<u></u>ciEnv*, ciMethod*,<br>
int)+0x176<br>
V  [libjvm.so+0x44ba9e]<br>
 CompileBroker::invoke_<u></u>compiler_on_method(<u></u>CompileTask*)+0x33e<br>
V  [libjvm.so+0x44c87d]  CompileBroker::compiler_<u></u>thread_loop()+0x43d<br>
V  [libjvm.so+0x94d5ff]  JavaThread::thread_main_inner(<u></u>)+0xdf<br>
V  [libjvm.so+0x94d705]  JavaThread::run()+0xf5<br>
V  [libjvm.so+0x815538]  java_start(Thread*)+0x108<br>
<br>
Code Cache  [0x00002b091755c000, 0x00002b091869c000, 0x00002b091a55c000)<br>
 total_blobs=7033 nmethods=6349 adapters=634 free_code_cache=31715Kb<br>
largest_free_block=32247296<br>
<br>
Memory mappings around the code cache virtual space (bolded line is<br>
the code cache segment, I believe, based on the Code Cache output above):<br>
<br>
*2b091755c000-2b091869c000 rwxp 00000000 00:00 0*<br>
2b09186ac000-2b091d66f000 rw-p 00000000 00:00 0<br>
2b091d66f000-2b091d670000 ---p 00000000 00:00 0<br>
2b091d670000-2b091d770000 rwxp 00000000 00:00 0<br>
2b091d770000-2b091d771000 ---p 00000000 00:00 0<br>
2b091d771000-2b091d871000 rwxp 00000000 00:00 0<br>
2b091d871000-2b091d872000 ---p 00000000 00:00 0<br>
2b091d872000-2b091d972000 rwxp 00000000 00:00 0<br>
<br>
/proc/meminfo:<br>
MemTotal:       49521668 kB<br>
MemFree:         5596796 kB<br>
Buffers:          294684 kB<br>
Cached:         34205856 kB<br>
SwapCached:            0 kB<br>
Active:         12745128 kB<br>
Inactive:       28516788 kB<br>
Active(anon):    9280636 kB<br>
Inactive(anon):  3090264 kB<br>
Active(file):    3464492 kB<br>
Inactive(file): 25426524 kB<br>
Unevictable:       14420 kB<br>
Mlocked:           14420 kB<br>
SwapTotal:             0 kB<br>
SwapFree:              0 kB<br>
Dirty:             20392 kB<br>
Writeback:             0 kB<br>
AnonPages:       6776540 kB<br>
Mapped:          6292204 kB<br>
Shmem:           5604620 kB<br>
Slab:            1828656 kB<br>
SReclaimable:    1567928 kB<br>
SUnreclaim:       260728 kB<br>
KernelStack:        4648 kB<br>
PageTables:        58800 kB<br>
NFS_Unstable:          0 kB<br>
Bounce:                0 kB<br>
WritebackTmp:          0 kB<br>
CommitLimit:    47045584 kB<br>
Committed_AS:   46046480 kB<br>
VmallocTotal:   34359738367 kB<br>
VmallocUsed:      460188 kB<br>
VmallocChunk:   34333703480 kB<br>
HugePages_Total:       0<br>
HugePages_Free:        0<br>
HugePages_Rsvd:        0<br>
HugePages_Surp:        0<br>
Hugepagesize:       2048 kB<br>
DirectMap4k:        8192 kB<br>
DirectMap2M:     2080768 kB<br>
DirectMap1G:    48234496 kB<br>
<br>
Memory: 4k page, physical 49521668k(5596796k free), swap 0k(0k free)<br>
<br>
* overcommit is turned off<br>
<br>
So the code heap was attempting to expand by 65kb at a fixed address.<br>
 There appears to be a 65kb mapping available between the end of the<br>
current code heap mapping (2b091755c000-2b091869c000) and the next one<br>
(2b09186ac000-2b091d66f000).  There's about 30mb of free space left<br>
(reserved, but uncommitted I take it) in the virtual space, so it's a<br>
bit puzzling given there's ample physical mem available.  Only thing I<br>
can think of is expansion fails because it cannot get contiguous<br>
space, but then I can't reconcile that with the mem mapping above.<br>
<br>
Does anyone have any ideas?<br>
<br>
Let me know if you need additional info from the hs_err file.<br>
<br>
Thanks<br>
<br>
</blockquote>
<br>
</blockquote>
</blockquote></div>