<div dir="ltr">Hi Stefan,<div><br></div><div>Unfortunately, overcommit_memory=2 isn't the cause. The original bug reporter ran the test again in a 3GB virtual machine [1], and saw:</div><div><br></div><div><div>$ cat /proc/sys/vm/overcommit_memory</div>
<div>0</div><div>$ cat /proc/sys/vm/overcommit_ratio</div><div>50</div><div>$ ~/jdk1.8.0/bin/java</div><div>Error occurred during initialization of VM</div><div>Could not allocate metaspace: 1073741824 bytes</div></div><div>
<br></div><div>- Kris</div><div><br></div><div>[1]: <a href="http://hllvm.group.iteye.com/group/topic/39890?page=2#post-260951">http://hllvm.group.iteye.com/group/topic/39890?page=2#post-260951</a></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, Apr 10, 2014 at 12:54 PM, Krystal Mok <span dir="ltr"><<a href="mailto:rednaxelafx@gmail.com" target="_blank">rednaxelafx@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hi Stefan,<div><br></div><div>Thank you for your explanation. The overcommit_memory=2 theory looks reasonable.</div><div>Let me pass it back to the original discussion thread and see if that's the case.</div>
<div><br></div><div>Anyway, it'd still be nice if Java could start in a more graceful way.</div><div><br></div><div>Thanks,</div><div>Kris</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br>
<div class="gmail_quote">On Thu, Apr 10, 2014 at 4:25 AM, Stefan Karlsson <span dir="ltr"><<a href="mailto:stefan.karlsson@oracle.com" target="_blank">stefan.karlsson@oracle.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>
On 2014-04-10 11:29, Krystal Mok wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi HotSpot runtime team,<br>
<br>
I'd like to report a bug on behave of someone from a discussion thread [1] from the HLLVM forum that I run.<br>
<br>
This is the symptom he reported:<br>
<br>
$ uname -a<br>
Linux IS-CDSM-166 2.6.32.61-cds-64 #1 SMP PREEMPT Tue Feb 25 20:23:18 PST 2014 x86_64 x86_64 x86_64 GNU/Linux<br>
<br>
$ java -version<br>
Error occurred during initialization of VM<br>
Could not allocate metaspace: 1073741824 bytes<br>
<br>
$ java -XX:MaxMetaspaceSize=1m -XX:MetaspaceSize=1m -version<br>
Error occurred during initialization of VM<br>
Could not allocate metaspace: 1073741824 bytes<br>
<br>
Apparently the error message says it's trying to allocate a 1GB metaspace, but failed. This seems to be related to JDK-8003424: Enable Class Data Sharing for CompressedOops [2].<br>
<br>
He further tested working around with -XX:-<u></u>UseCompressedClassPointers, and it worked:<br>
<br>
# java -XX:ClassMetaspaceSize=512m -version<br>
Unrecognized VM option 'ClassMetaspaceSize=512m'<br>
Did you mean 'MetaspaceSize=<value>'?<br>
Error: Could not create the Java Virtual Machine.<br>
Error: A fatal exception has occurred. Program will exit.<br>
</blockquote>
<br></div>
The correct flag to use is: -XX:CompressedClassSpaceSize=<u></u>512m<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
$ java -XX:-<u></u>UseCompressedClassPointers -version<br>
java version "1.8.0"<br>
Java(TM) SE Runtime Environment (build 1.8.0-b132)<br>
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)<br>
<br>
The tests above were run in a virtual machine with 3GB of memory.<br>
When he bumped up the memory for his virtual machine to 8GB, the VM is able to start without the workaround.<br>
<br>
Has this behavior been seen before?<br>
</blockquote>
<br></div>
I think you'll see this behavior if overcommit_memory is set to 2.<br>
<br>
$ man 5 proc<br>
---<br>
/proc/sys/vm/overcommit_memory<br>
This file contains the kernel virtual memory accounting mode. Values are:<br>
<br>
0: heuristic overcommit (this is the default)<br>
1: always overcommit, never check<br>
2: always check, never overcommit<br>
<br>
In mode 0, calls of mmap(2) with MAP_NORESERVE are not checked, and the default check is very weak, leading to the risk of getting a process "OOM-killed". Under Linux 2.4 any nonzero value implies mode 1. In mode 2<br>
(available since Linux 2.6), the total virtual address space on the system is limited to (SS + RAM*(r/100)), where SS is the size of the swap space, and RAM is the size of the physical memory, and r is the contents of<br>
the file /proc/sys/vm/overcommit_ratio.<br>
---<br>
<br>
Could this be the reason why we fail to reserve the 1 GB large compressed class space?<br>
<br>
StefanK<div><div><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Best regards,<br>
Kris<br>
<br>
[1]: <a href="http://hllvm.group.iteye.com/group/topic/39890" target="_blank">http://hllvm.group.iteye.com/<u></u>group/topic/39890</a><br>
[2]: <a href="https://bugs.openjdk.java.net/browse/JDK-8003424" target="_blank">https://bugs.openjdk.java.net/<u></u>browse/JDK-8003424</a><br>
</blockquote>
<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>