Unable to start VM with JDK8 on Linux/x64

[Mikael Gerdin]

Kris,

On Sunday 13 April 2014 18.53.56 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

Is there a virtual memory ulimit set? (ulimit -v)

What heap sizing command line flags are set?
There is (AFAIK) nothing special with the way we reserve memory for the 
compressed class space compared to how we reserve memory for the main Java 
heap.
Running with -XX:-UseCompressedClassPointers and increasing the maximum heap 
size with 1G should give the same problems I think.

/Mikael

> 
> - 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> 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> 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