CRR (S/M): 7049999: G1: Make the G1PrintHeapRegions output consistent and complete

[Poonam Bajaj]

Hi Tony,

The new output looks completely different from the earlier output. e.g. 
here's output generated with jdk7-b141:

 added region to incremental cset (LHS) 0:[0x02c00000, 0x02d00000], top 
0x02c53040, young YES
new alloc region 1:[0x02d00000,0x02e00000], top 0x02d00000
 added region to incremental cset (LHS) 1:[0x02d00000, 0x02e00000], top 
0x02e00000, young YES
new alloc region 2:[0x02e00000,0x02f00000], top 0x02e00000
new alloc region 1:[0x02d00000,0x02e00000], top 0x02d00000
 added region to incremental cset (LHS) 1:[0x02d00000, 0x02e00000], top 
0x02e00000, young YES
new alloc region 2:[0x02e00000, 0x02f00000], top 0x02e01000
.....
new alloc region 19:[0x03f00000,0x04000000], top 0x03f00000
 added region to incremental cset (RHS) 19:[0x03f00000, 0x04000000], top 
0x03f04000, young YES
new alloc region 17:[0x03d00000,0x03e00000], top 0x03d00000

It prints the index of the region, and whether it is added to eden or 
survivor (based on LHS
or RHS).

The index of the region is missing from the new output. I think it would 
be good
to have it; makes it easier to read the logs.

In the new output, I see events like COMMIT, ALLOC, UNCOMMIT, RETIRE.
Could you please explain these ?

G1HR COMMIT [0x72700000,0x72800000]
 G1HR ALLOC(Eden) 0x6e800000
Will gc in between benchmarks
 G1HR RETIRE 0x6e800000 0x6e87bd98
 G1HR #StartFullGC 1
 G1HR UNCOMMIT [0x72700000,0x72800000]

There are some numbers printed between the log entries. What are 
these numbers ?
 G1HR ALLOC(ContinuesH) 0x6f100000 0x6f102010
3153920						<-----									
931067                                          <-----
 G1HR COMMIT [0x6f200000,0x6f300000]


For the ALLOC and CSET entries, only one address is printed, looks like 
it is the lower
bound of the region. It would be good to have both the bounds printed 
(along with the index).

 G1HR #StartGC 2
 G1HR CSET 0x6e900000
 G1HR COMMIT [0x6f800000,0x6f900000]
 G1HR ALLOC(Old) 0x6f800000
 G1HR RETIRE 0x6f800000 0x6f826838



Thanks,
Poonam



On 6/22/2011 1:04 AM, Tony Printezis wrote:
> Hi,
>
> Could I get a couple of folks to look at this?
>
> http://cr.openjdk.java.net/~tonyp/7049999/webrev.0/
>
> +G1PrintHeapRegions is a very helpful debugging feature that we have 
> used a lot in the past. It'll be very helpful in the long run to 
> ensure that it generates more complete output to save us having to 
> deduce some of it. What was missing in the past was:
>
> * output for humongous region allocations
> * output per region post compaction (as compaction changes the shape 
> of the heap)
> * output when regions are reclaimed during cleanup
>
> Further enhancements include:
>
> * commit / uncommit events
> * trimmed the output to keep the generated log files smaller while not 
> losing any information
> * introduced the G1HRPrinter class and all output goes through it to 
> ensure consistency
>
> I attached an example of the new output.
>
> Tony
>

-- 
Best regards, Poonam

Sun, an Oracle company
Sun, an Oracle Company
Poonam Bajaj | Staff Engineer
Phone: +66937451 <tel:+66937451> | Mobile: +9844511366 <tel:+9844511366>
JVM Sustaining Engineering
| Bangalore
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20110622/e83babe1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sun-oracle-logo.gif
Type: image/gif
Size: 2088 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20110622/e83babe1/sun-oracle-logo.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: green-for-email-sig_0.gif
Type: image/gif
Size: 356 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20110622/e83babe1/green-for-email-sig_0.gif>