RFR (S): 8014240 G1: Add remembered set size information to output of G1PrintRegionLivenessInfo

[Thomas Schatzl]

Hi all,

  can I have reviews for the following small change?

The change adds an additional column to the -XX:+G1PrintRegionLivenessInfo output that shows remembered set memory usage on a per region basis. It includes an accumulated total at the end in the footer. This is required to better evaluate remembered set usage on a reasonably detailed basis, while not flooding the log (if e.g. printing this information at every GC).

E.g. before

### PHASE Post-Sorting @ 10.215
### HEAP  committed: 0x0000000748e00000-0x000000074ac00000  reserved: 0x0000000748e00000-0x0000000800000000  region-size: 1048576
###
###   type                         address-range       used  prev-live  next-live          gc-eff
###                                                 (bytes)    (bytes)    (bytes)      (bytes/ms)
###   OLD  0x0000000749600000-0x0000000749700000      13144        128          0        740134.1
###   OLD  0x0000000749000000-0x0000000749100000    1044816     241608          0        102688.9
[...]
###
### SUMMARY  capacity: 33.00 MB  used: 19.30 MB / 58.48 %  prev-live: 16.76 MB / 50.77 %  next-live: 15.67 MB / 47.49 %

after:

### PHASE Post-Sorting @ 10.215
### HEAP  committed: 0x0000000748e00000-0x000000074ac00000  reserved: 0x0000000748e00000-0x0000000800000000  region-size: 1048576
###
###   type                         address-range       used  prev-live  next-live          gc-eff     remset
###                                                 (bytes)    (bytes)    (bytes)      (bytes/ms)    (bytes)
###   OLD  0x0000000749600000-0x0000000749700000      13144        128          0        740134.1       3112
###   OLD  0x0000000749000000-0x0000000749100000    1044816     241608          0        102688.9       4960
[...]
###
### SUMMARY  capacity: 33.00 MB  used: 19.30 MB / 58.48 %  prev-live: 16.76 MB / 50.77 %  next-live: 15.67 MB / 47.49 %  remset: 0.27 MB

The summary in the footer includes a grand total consisting of not only the per-region sizes, but also free list and additional static memory usage of the remembered set.

Details for the change:

- in heapRegionRemSet.cpp, method OtherRegionsTable::mem_size() there is a small optimization for calculating the remembered set size. Instead of iterating the fine remset (PerRegionTable) we calculate the value by multiplying the size of a single PerRegionTable by the number of entries. This, while the code is not performance critical, improves performance significantly, especially with large remembered sets. (Tested manually by extra measurement code not present in the change).

This change is safe as _n_fine_entries always contains the number of PRTs for this remembered set, and mem_size() for a PRT is constant. The former condition is e.g. checked in OtherRegionsTable::occ_fine(), the assert in that code checks the latter condition for two exemplary elements of the list of PRTs (since we manage them using a doubly linked list, we use the first and last element). This fact can also be checked by looking at the PerRegionTable constructor, where the bitmap backing the PRT is allocated.

- the test case waits for a completed marking and checks whether there is a "remset" string in the summary footer. It does so by first allocating a large object and setting the IHOP very low, and then waiting a little bit. It seems that the given timeout is sufficient (at that time the heap is practically empty except for the given LOB).

Webrev
http://cr.openjdk.java.net/~tschatzl/8014240/webrev

Bugs.sun.com
http://bugs.sun.com/view_bug.do?bug_id=8014240

Jira:
https://jbs.oracle.com/bugs/browse/JDK-8014240

Testing:
jprt, test cases, manual runs of dacapo benchmarks with/without G1PrintRegionLivenessInfo enabled

Thanks,
  Thomas