United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-8016556 G1: Use ArrayAllocator for BitMaps
JDK-8016556 : G1: Use ArrayAllocator for BitMaps

Details
Type:
Bug
Submit Date:
2013-06-13
Status:
Resolved
Updated Date:
2013-07-02
Project Name:
JDK
Resolved Date:
2013-06-19
Component:
hotspot
OS:
Sub-Component:
gc
CPU:
Priority:
P3
Resolution:
Fixed
Affected Versions:
Fixed Versions:
hs24 (b50)

Related Reports
Backport:
Backport:
Backport:
Backport:
Backport:

Sub Tasks

Description
In the constructor for the ConcurrentMark class in G1 we set up one bit map per worker thread:

  for (uint i = 0; i < _max_worker_id; ++i) {
    ...
    _count_card_bitmaps[i] = BitMap(card_bm_size, false);
    ...
  }

Each of these bitmaps are malloced, which means that the amount of C-heap we require grows with the number of GC worker threads we have. On a machine with many CPUs we get many worker threads by default. For example, on scaaa007 I get 79 GC worker threads. The size of the bitmaps also scale with the heap size, so since this large machine has a lot of memory we get a large default heap as well.

Here is the output from just running java -version with G1 on scaaa007:

$ java -d64 -XX:+UseG1GC -XX:+PrintMallocStatistics -version
java version "1.8.0-ea-fastdebug"
Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b92)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b34-fastdebug, mixed mode)
allocation stats: 35199 mallocs (221MB), 13989 frees (0MB), 35MB resrc

We malloc 221MB just by starting the VM. Most of the large allocations are due to the BitMap allocations. I have a patch that changes the BitMap allocations to use the ArrayAllocator instead. That class uses mmap on Solaris if the size is larger than 64K.

With this patch the output looks like this:

$ java -d64 -XX:+UseG1GC -XX:+PrintMallocStatistics -version
java version "1.8.0-ea-fastdebug"
Java(TM) SE Runtime Environment (build 1.8.0-ea-fastdebug-b93)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b34-internal-201306130943.brutisso.hs-gc-g1-mmap-fastdebug, mixed mode)
allocation stats: 35217 mallocs (31MB), 14031 frees (0MB), 35MB resrc

We are down to 31MB.

Note that the ArrayAllocator only has this effect on Solaris machines. Also note that I have not reduced the total amount of memory, just moved it from the C-heap to mapped memory.
                                    

Comments
7u40-critical-request justification:
This is not a regression compared to previous releases, but since our test labs have gotten new hardware with more memory and more CPUs we have started to see these failures in our testing. To reduce the number of test failures in the 7u40 testing we need this fix.

The fix will only make a difference on Solaris machines. There the BitMap memory will be mmapped instead of malloced. This is a fairly low risk change.
                                     
2013-06-18
Approve critical request as RDP2 only start on 6/19.
                                     
2013-06-18
URL:   http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/a51e6c9c3210
User:  brutisso
Date:  2013-06-19 09:15:08 +0000

                                     
2013-06-19
noreg-hard motivation:

This is only an issue on Solaris x86 with large heaps. There is no support in our infrastructure for writing a test that is only run under these conditions.
                                     
2013-06-25



Hardware and Software, Engineered to Work Together