Unable to start VM with JDK8 on Linux/x64

Stefan Karlsson stefan.karlsson at oracle.com
Thu Apr 10 11:25:51 UTC 2014


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



More information about the hotspot-runtime-dev mailing list