CRR (S/M): 7075646: G1: fix inconsistencies in the monitoring data

Tony Printezis tony.printezis at oracle.com
Tue Aug 16 08:33:03 PDT 2011


Hi all,

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):

http://cr.openjdk.java.net/~tonyp/7075646/webrev.2/

If you started looking at the webrev below, the only change is this one 
(in g1MonitoringSupport.cpp):

  // 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

Tony Printezis wrote:
> Hi all,
>
> Thanks to Jon Masa for several good suggestions, here's the updated 
> webrev:
>
> http://cr.openjdk.java.net/~tonyp/7075646/webrev.1/
>
> Tony
>
> Tony Printezis wrote:
>> Hi all,
>>
>> I would like a couple of code reviews for some fixes in the G1 
>> monitoring code:
>>
>> http://cr.openjdk.java.net/~tonyp/7075646/webrev.0/
>>
>> 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.
>>
>> Tony
>>
>


More information about the hotspot-gc-dev mailing list