JDK-8016556 : G1: Use ArrayAllocator for BitMaps
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2013-06-13
  • Updated: 2014-09-15
  • Resolved: 2013-06-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 Other
7u40Fixed 8Fixed hs24Fixed
Related Reports
Relates :  
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
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.
25-06-2013

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.
18-06-2013

Approve critical request as RDP2 only start on 6/19.
18-06-2013