CRR: 7032531: G1: enhance GC logging to include more accurate eden / survivor size transitions (S/XS)

[Y. S. Ramakrishna]

On 06/07/11 13:24, Tony Printezis wrote:
> Ramki,
> 
> You're bringing a very good point, as always!
> 
> Both the max eden and survivor sizes can potentially change at the end 
> of each GC. I was going to send those resizing decision to the 
> "ergonomic decisions" output (for which I recently opened a CR - 
> 7050392). Including them here like the max heap size is a reasonably 
> suggestion. Note, however, that the max heap size is actually a slightly 
> different concept to the max eden / survivor sizes. The max heap size 
> indicates that we have actually reserved that much space. The max eden / 
> survivor sizes are instead a goal and we'll reserve that space on demand 
> (and in some cases we might not be able to: imagine if suddenly the heap 
> fills up with a humongous object). So I decided not to show those in a 
> similar way as the max heap size.

OK, i see.

> 
> Maybe I'm being too pedantic here?

Probably not; it's best to give less info (as you've decided to)
than give more and have the users confused as to what happened with
that space... may be :-)

FWIW, i think it's fine to provide that extra info in the ergo decisions
output, as you've chosen to,

-- ramki

> 
> Tony
> 
> On 06/07/2011 03:31 PM, Y. S. Ramakrishna wrote:
>> Hi Tony -- high level question: Does it make sense in G1
>> to report the "capacity" of Eden/Survivor (or Eden+Survivor)
>> after a scavenge, or does that not make sense because
>> perhaps it's dynamically decided based on other factors
>> and so all that really matters is the capacity of the whole
>> heap (reported as 125 MB in your snippet below).
>>
>> thanks.
>> -- ramki
>>
>> On 06/07/11 11:10, Tony Printezis wrote:
>>> Hi all,
>>>
>>> Could I have a couple of reviews for this change?
>>>
>>> http://cr.openjdk.java.net/~tonyp/7032531/webrev.0/
>>>
>>> This enhances the G1 +PrintGCDetails output to include how much space 
>>> there is in the eden and survivor regions before / after a GC. Here's 
>>> an example of the output:
>>>
>>>    [Eden: 18M->0B Survivors: 1024K->2048K Heap: 27M(105M)->12M(125M)]
>>>
>>> It shows that the eden had 18MB before the GC and it's empty after it 
>>> (as expected!), the survivors were 1MB before the GC and grew to 2MB 
>>> after the GC, the used space in the heap fell from 27MB to 12MB, and 
>>> finally the heap size grew from 105MB to 125MB.
>>>
>>> Note that, currently, the eden / survivor sizes that are reported are 
>>> not very accurate. They are currently calculated as region_num * 
>>> region_size. It'd be better if they were calculated as the used byte 
>>> total in the eden and survivor regions. But this would require a fair 
>>> amount of extra changes to do (I'd rather avoid iterating over them 
>>> to calculate that). We'll do that change when we revamp the region 
>>> lists that keep track of the eden / survivor regions (which is 
>>> currently work-in-progress).
>>>
>>> Tony
>>>