Unable to start VM with JDK8 on Linux/x64

[Stefan Karlsson]

Hi Kris,

On 2014-04-14 03:53, Krystal Mok wrote:
> Hi Stefan,
>
> Unfortunately, overcommit_memory=2 isn't the cause. The original bug 
> reporter ran the test again in a 3GB virtual machine [1], and saw:
>
> $ cat /proc/sys/vm/overcommit_memory
> 0
> $ cat /proc/sys/vm/overcommit_ratio
> 50
> $ ~/jdk1.8.0/bin/java
> Error occurred during initialization of VM
> Could not allocate metaspace: 1073741824 bytes

Then I don't know. Maybe the virtualization layer prevents the overcommit?

StefanK

>
> - Kris
>
> [1]: http://hllvm.group.iteye.com/group/topic/39890?page=2#post-260951
>
>
> On Thu, Apr 10, 2014 at 12:54 PM, Krystal Mok <rednaxelafx at gmail.com 
> <mailto:rednaxelafx at gmail.com>> wrote:
>
>     Hi Stefan,
>
>     Thank you for your explanation. The overcommit_memory=2 theory
>     looks reasonable.
>     Let me pass it back to the original discussion thread and see if
>     that's the case.
>
>     Anyway, it'd still be nice if Java could start in a more graceful way.
>
>     Thanks,
>     Kris
>
>
>     On Thu, Apr 10, 2014 at 4:25 AM, Stefan Karlsson
>     <stefan.karlsson at oracle.com <mailto:stefan.karlsson at oracle.com>>
>     wrote:
>
>
>         On 2014-04-10 11:29, Krystal Mok wrote:
>
>             Hi HotSpot runtime team,
>
>             I'd like to report a bug on behave of someone from a
>             discussion thread [1] from the HLLVM forum that I run.
>
>             This is the symptom he reported:
>
>             $ uname -a
>             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
>
>             $ java -version
>             Error occurred during initialization of VM
>             Could not allocate metaspace: 1073741824 bytes
>
>             $ java -XX:MaxMetaspaceSize=1m -XX:MetaspaceSize=1m -version
>             Error occurred during initialization of VM
>             Could not allocate metaspace: 1073741824 bytes
>
>             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].
>
>             He further tested working around with
>             -XX:-UseCompressedClassPointers, and it worked:
>
>             # java -XX:ClassMetaspaceSize=512m -version
>             Unrecognized VM option 'ClassMetaspaceSize=512m'
>             Did you mean 'MetaspaceSize=<value>'?
>             Error: Could not create the Java Virtual Machine.
>             Error: A fatal exception has occurred. Program will exit.
>
>
>         The correct flag to use is: -XX:CompressedClassSpaceSize=512m
>
>
>
>             $ java -XX:-UseCompressedClassPointers -version
>             java version "1.8.0"
>             Java(TM) SE Runtime Environment (build 1.8.0-b132)
>             Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)
>
>             The tests above were run in a virtual machine with 3GB of
>             memory.
>             When he bumped up the memory for his virtual machine to
>             8GB, the VM is able to start without the workaround.
>
>             Has this behavior been seen before?
>
>
>         I think you'll see this behavior if overcommit_memory is set to 2.
>
>         $ man 5 proc
>         ---
>                /proc/sys/vm/overcommit_memory
>                       This file contains the kernel virtual memory
>         accounting mode.  Values are:
>
>                              0: heuristic overcommit (this is the default)
>                              1: always overcommit, never check
>                              2: always check, never overcommit
>
>                       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
>                       (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
>                       the file /proc/sys/vm/overcommit_ratio.
>         ---
>
>         Could this be the  reason why we fail to reserve the 1 GB
>         large compressed class space?
>
>         StefanK
>
>
>
>             Best regards,
>             Kris
>
>             [1]: http://hllvm.group.iteye.com/group/topic/39890
>             [2]: https://bugs.openjdk.java.net/browse/JDK-8003424
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20140414/3cf419be/attachment.html>