<div dir="ltr">Hi Dan,<div><br></div><div>Thanks for the pointer.  Here's the relevant line:</div><div><br></div><div>Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x00002b091869c000, 65536, 1) failed; error='Cannot allocate memory' (errno=12)<br>
</div><div><br></div><div>So it confirms the fixed address at which it's trying to commit and the 65kb size.  The address matches the end of the currently committed code heap region, but still somewhat puzzling as to why ENOMEM is returned given the rest of the output in the error report.  Perhaps there was a transient spike in mem consumption when mmap failed but the condition disappeared (ie. mem was free'd back to os by another process) by the time the error reporter pulled mem stats from the kernel?</div>
<div><br></div><div>Thanks </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 30, 2014 at 10:14 AM, Daniel D. Daugherty <span dir="ltr"><<a href="mailto:daniel.daugherty@oracle.com" target="_blank">daniel.daugherty@oracle.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">When 'os::commit_memory()' fails, there should be a message like the<br>
following in stderr for the Java process:<br>
<br>
Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(<u></u>0xfffffd7fe8c00000, 2097152, 1) failed; error='Resource temporarily unavailable' (errno=11)<br>
<br>
The address and size should match what you see in the stack trace<br>
which provides confirmation that we have the right mesg, but the<br>
important piece is the errno value...<br>
<br>
Dan<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 5/29/14 7:20 PM, Vitaly Davidovich wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yes, swap and overcommit are turned off.  But, there's substantial free<br>
physical memory available and looks like 65kb available to expand the code<br>
heap contiguoisly.  So I'm a bit puzzled ...<br>
<br>
Taking Chris' suggestion and cc'ing hotspot dev ...<br>
<br>
Sent from my phone<br>
On May 29, 2014 8:47 PM, "Vladimir Kozlov" <<a href="mailto:vladimir.kozlov@oracle.com" target="_blank">vladimir.kozlov@oracle.com</a>><br>
wrote:<br>
<br>
<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>
<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>
  Hi guys,<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
<br>
</blockquote></blockquote></blockquote></blockquote>
<br>
</div></div></blockquote></div><br></div>