RFR (S/M): 8014078: G1: improve remembered set summary information by providing per region type information

[Thomas Schatzl]

Hi all,

  can I have reviews for the following change? It has already been
reviewed earlier
(http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-June/007431.html), but not pushed at that time because of concerns of introducing bugs so late in the jdk8 release process.

Changes in the code base have shown that this has not been a
particularly good idea, as this requires lots of work; since the change
itself is extremely low risk, includes test cases and provides useful
information, so we think it is okay to push.

This re-review is caused by mentioned changes: particularly the nmethod
changes (CR 7145569) added a new kind of remembered set entries which
need to be handled by the output.

This CR has the following effects:

- changes the output of -XX:+G1SummarizeRSetStats to contain a breakdown
of remembered set data structures by region type, i.e. young, humongous,
old, and free regions.

The resulting output looks as follows (just a -version run):

 Cumulative RS summary

 Recent concurrent refinement statistics
  Processed 0 cards
  Of 0 completed buffers:
            0 (  0.0%) by concurrent RS threads.
            0 (  0.0%) by mutator threads.
  Did 0 coarsenings.
  Concurrent RS threads times (s)
          0.00     0.00     0.00     0.00
  Concurrent sampling threads times (s)
          0.00

 Current rem set statistics
  Total per region rem sets sizes = 531K. Max = 2K.
           2K (  0.5%) by 1 Young regions
           0K (  0.0%) by 0 Humonguous regions
         528K ( 99.5%) by 183 Free regions
           0K (  0.0%) by 0 Old regions
   Static structures = 91K, free_lists = 0K.
    0 occupied cards represented.
            0 (  0.0%) entries by 1 Young regions
            0 (  0.0%) entries by 0 Humonguous regions
            0 (  0.0%) entries by 183 Free regions
            0 (  0.0%) entries by 0 Old regions
    Region with largest rem set = 0:(E)[0x0000000748e00000,0x0000000748e580e0,0x0000000748f00000], size = 2K, occupied = 0K.
  Total heap region code root sets sizes = 20K.  Max = 0K.
           0K (  0.5%) by 1 Young regions
           0K (  0.0%) by 0 Humonguous regions
          20K ( 99.5%) by 183 Free regions
           0K (  0.0%) by 0 Old regions
    0 code roots represented.
            0 (  0.0%) elements by 1 Young regions
            0 (  0.0%) elements by 0 Humonguous regions
            0 (  0.0%) elements by 183 Free regions
            0 (  0.0%) elements by 0 Old regions
    Region with largest amount of code roots = 183:(F)[0x0000000754500000,0x0000000754500000,0x0000000754600000], size = 0K, num_elems = 0.

- cleanup of output to be more readable (i.e. CR 8023253)

- cleanup of the test cases: a large part of the code base for this CR
reuses utility methods from 8013895, so I went ahead and factored out
common code into a separate file that both the tests for 801385 and this
CR use.

- all calculated memory size values are rounded downwards, instead of
sometimes up and sometimes down as earlier; I could not find a clear pattern
so I decided to always round down but if there is some reason to do
otherwise let me know.

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

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

Testing:
jprt, jtreg test case for 8014078 and 8013895

Hth,
  Thomas