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