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

[Y. S. Ramakrishna]

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
>