Unable to start VM with JDK8 on Linux/x64

[Krystal Mok]

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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20140410/d80a06a6/attachment.html>