CRR (S/M): 7075646: G1: fix inconsistencies in the monitoring data
tony.printezis at oracle.com
Tue Aug 16 08:33:03 PDT 2011
New webrev with a small fix to resolve an issue I came across during
testing (I was forgetting to update the new generation capacity after
the eden / survivor capacities had been updated):
If you started looking at the webrev below, the only change is this one
// Finally, give the rest to the old space...
_old_committed += committed;
// ..and calculate the young gen committed.
_young_gen_committed = _eden_committed + _survivor_committed;
Tony Printezis wrote:
> Hi all,
> Thanks to Jon Masa for several good suggestions, here's the updated
> Tony Printezis wrote:
>> Hi all,
>> I would like a couple of code reviews for some fixes in the G1
>> monitoring code:
>> The main motivation behind these changes is that G1's jstat output
>> has inconsistencies and has been causing a few test failures. Here's
>> a quick summary of the changes:
>> - Reworked the way the capacities of the various spaces are
>> calculated so that only the eden space used counter needs to be
>> updated when a new eden region is allocated.
>> - Now the values of the various sizes that need to be reported are
>> calculated synchronously in all the appropriate places in the code
>> and stored so that they do not need to be recalculated every time
>> they are required.
>> - The jstat counters for the young / old gen capacity are now
>> correctly updated.
>> - We ensure that when we are reporting a capacity to jstat we
>> artficially pad it so that it's never 0 (as jstat does not handle 0
>> capacities gracefully).
>> I attached a file that has before / after output comparisons, along
>> with some commentary, for the various jstat GC parameters.
More information about the hotspot-gc-dev