Max possible heap size for Concurrent Mark Sweep collector.

[Alexey Ragozin]

Box has 256GiB of RAM and no other memory consuming processes were run at
that time.
Kernel version 3.0.80 (Suse Enterprise Linux 11)

I have a look at code base and it seams that "CMS bit map allocation
failure" raised if JVM failed to allocate continuous address space for
bitmap. Actual memory commit is few line below.

    bool CMSBitMap::allocate(MemRegion mr) {
      _bmStartWord = mr.start();
      _bmWordSize  = mr.word_size();
      ReservedSpace brs(ReservedSpace::allocation_align_size_up(
                         (_bmWordSize >> (_shifter + LogBitsPerByte)) + 1));
      if (!brs.is_reserved()) {
        warning("CMS bit map allocation failure");
        return false;
      }
      // For now we'll just commit all of the bit map up fromt.
      // Later on we'll try to be more parsimonious with swap.
      if (!_virtual_space.initialize(brs, brs.size())) {
        warning("CMS bit map backing store failure");
        return false;
      }

How it could be possible for 64 bit process?

Regards,
Alexey



On Thu, Sep 11, 2014 at 2:57 AM, Tao Mao <yiyeguhu at gmail.com> wrote:

> How large is the machine's memory? and how many vm's did you try to run on
> one machine at the same time?
>
> On Wed, Sep 10, 2014 at 2:53 PM, Alexey Ragozin <alexey.ragozin at gmail.com>
> wrote:
>
>> Hi,
>>
>> Sometimes ago we have tried to setup 200GiB heap per JVM using CMS GC.
>> Oracle HotSpot JVM have failed to start with following error
>>
>> Java HotSpot(TM) 64-Bit Server VM warning: CMS bit map allocation failure
>> Java HotSpot(TM) 64-Bit Server VM warning: Failed to allocate CMS Bit Map
>> Error occurred during initialization of VM
>> Could not create CMS collector
>> Error: Could not create the Java Virtual Machine.
>> Error: A fatal exception has occurred. Program will exit.
>>
>> JVM command line
>>
>> /usr/java/jdk1.7.0_60/bin/java -d64 -verbose:gc -XX:+UseConcMarkSweepGC
>> -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xmn512m
>> -XX:MaxTenuringThreshold=1 -Xms200G -Xmx200G
>> -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=90
>> -Duse-cached-field-op=false  -XX:MaxPermSize=1024m
>> -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=13521
>> -Dcom.sun.management.jmxremote.authenticate=false
>> -Dcom.sun.management.jmxremote.ssl=false -XX:-UsePopCountInstruction
>> APPLICATION_MAIN_CLASS ...
>>
>> We have reduced -Xmx to 180GiB and currently that is our configuration.
>> Provided amount of memory on our standard hardware setup, using JVM with
>> 400 GiB would be desirable.
>>
>> My question is
>>
>> Is that 200GiB fundamental limitation of CMS algorithm or it is something
>> what could be remedied?
>>
>> Any relevant pointers to open JDK code base would be appreciated.
>>
>> Regards,
>> Alexey
>>
>> _______________________________________________
>> hotspot-gc-use mailing list
>> hotspot-gc-use at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20140913/7db09f55/attachment.html>