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

[Tony Printezis]

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.

Maybe I'm being too pedantic here?

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