<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Tony,<br>
<br>
Thanks for the detailed explanation. The overall output looks good. <br>
<br>
<blockquote type="cite">
<blockquote type="cite">Will gc in between benchmarks
<br>
G1HR RETIRE 0x6e800000 0x6e87bd98 </blockquote>
<br>
The stop using the region for allocation so the retire even has the
region's top (in this case: 0x6e87bd98). Note that most regions are
full when retired and we ommit those events (we can easily deduce
those) to reduce the output volume.
<br>
</blockquote>
One small question - How do we find the full retired regions ? Do we
print a region when it is full ?<br>
<br>
<br>
Thanks,<br>
Poonam<br>
<br>
<br>
On 6/22/2011 8:48 PM, Tony Printezis wrote:
<blockquote cite="mid:4E0207DC.8000009@oracle.com" type="cite">Poonam,
<br>
<br>
Poonam Bajaj wrote:
<br>
<blockquote type="cite">Hi Tony,
<br>
<br>
The new output looks completely different from the earlier output.
<br>
</blockquote>
<br>
Indeed. The new output is more concise, more complete, and easier to
parse (and avoids some duplication).
<br>
<br>
<blockquote type="cite">e.g. here's output generated with jdk7-b141:
<br>
<br>
added region to incremental cset (LHS) 0:[0x02c00000, 0x02d00000], top
0x02c53040, young YES
<br>
new alloc region 1:[0x02d00000,0x02e00000], top 0x02d00000
<br>
</blockquote>
<br>
[snip]
<br>
<br>
<blockquote type="cite">It prints the index of the region,
<br>
</blockquote>
<br>
We can deduce that from the new output (from the COMMIT events which
are done in order), so it's unnecessary to print it.
<br>
<br>
<blockquote type="cite">and whether it is added to eden or survivor
(based on LHS
<br>
or RHS).
<br>
</blockquote>
<br>
Region allocation events have a region type in the new output too, like
ALLOC(Eden)
<br>
<br>
<blockquote type="cite">The index of the region is missing from the
new output. I think it would be good
<br>
to have it; makes it easier to read the logs.
<br>
</blockquote>
<br>
See above.
<br>
<br>
<blockquote type="cite">In the new output, I see events like COMMIT,
ALLOC, UNCOMMIT, RETIRE.
<br>
Could you please explain these ?
<br>
G1HR COMMIT [0x72700000,0x72800000]
<br>
</blockquote>
<br>
The heap is initialized or expanded and the region is freshly committed
(this was missing from the previous output).
<br>
<br>
<blockquote type="cite"> G1HR ALLOC(Eden) 0x6e800000
<br>
</blockquote>
<br>
The region just started being used for allocation. In this case it's an
Eden region and allocated to by a mutator thread. ALLOC events are also
generated for regions we allocate to during GC (for Survivor and Old,
depending on the type of region), as well as for humongous regions.
<br>
<br>
<blockquote type="cite">Will gc in between benchmarks
<br>
G1HR RETIRE 0x6e800000 0x6e87bd98
<br>
</blockquote>
<br>
The stop using the region for allocation so the retire even has the
region's top (in this case: 0x6e87bd98). Note that most regions are
full when retired and we ommit those events (we can easily deduce
those) to reduce the output volume.
<br>
<br>
<blockquote type="cite"> G1HR #StartFullGC 1
<br>
G1HR UNCOMMIT [0x72700000,0x72800000]
<br>
</blockquote>
<br>
Opposite to COMMIT. The heap got shrunk at the end of a Full GC.
<br>
<br>
<blockquote type="cite">There are some numbers printed between the
log entries. What are these numbers ?
<br>
G1HR ALLOC(ContinuesH) 0x6f100000 0x6f102010
<br>
3153920
<----- <br>
931067 <-----
<br>
G1HR COMMIT [0x6f200000,0x6f300000]
<br>
</blockquote>
<br>
Output from the benchmark (_201_compress).
<br>
<br>
<blockquote type="cite">For the ALLOC and CSET entries, only one
address is printed, looks like it is the lower
<br>
bound of the region. </blockquote>
<br>
Indeed.
<br>
<br>
<blockquote type="cite">It would be good to have both the bounds
printed (along with the index).
<br>
</blockquote>
<br>
This was done to reduce the output volume. Both bounds are only printed
when a region is committed / uncommitted.
<br>
<br>
Tony
<br>
<br>
<blockquote type="cite"> G1HR #StartGC 2
<br>
G1HR CSET 0x6e900000
<br>
G1HR COMMIT [0x6f800000,0x6f900000]
<br>
G1HR ALLOC(Old) 0x6f800000
<br>
G1HR RETIRE 0x6f800000 0x6f826838
<br>
<br>
<br>
Thanks,
<br>
Poonam
<br>
<br>
<br>
<br>
On 6/22/2011 1:04 AM, Tony Printezis wrote:
<br>
<blockquote type="cite">Hi,
<br>
<br>
Could I get a couple of folks to look at this?
<br>
<br>
<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~tonyp/7049999/webrev.0/">http://cr.openjdk.java.net/~tonyp/7049999/webrev.0/</a>
<br>
<br>
+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:
<br>
<br>
* output for humongous region allocations
<br>
* output per region post compaction (as compaction changes the shape of
the heap)
<br>
* output when regions are reclaimed during cleanup
<br>
<br>
Further enhancements include:
<br>
<br>
* commit / uncommit events
<br>
* trimmed the output to keep the generated log files smaller while not
losing any information
<br>
* introduced the G1HRPrinter class and all output goes through it to
ensure consistency
<br>
<br>
I attached an example of the new output.
<br>
<br>
Tony
<br>
<br>
</blockquote>
<br>
-- <br>
Best regards, Poonam
<br>
<br>
Sun, an Oracle company
<br>
Sun, an Oracle Company
<br>
Poonam Bajaj | Staff Engineer
<br>
Phone: +66937451 <tel:+66937451> | Mobile: +9844511366
<tel:+9844511366>
<br>
JVM Sustaining Engineering
<br>
| Bangalore
<br>
Green Oracle <a class="moz-txt-link-rfc2396E" href="http://www.oracle.com/commitment"><http://www.oracle.com/commitment></a> Oracle is
committed to developing practices and products that help protect the
environment
<br>
<br>
</blockquote>
</blockquote>
<br>
<div class="moz-signature">-- <br>
Best regards, Poonam
<p><img src="cid:part1.08090505.05040806@oracle.com"
alt="Sun, an Oracle company" border="0" height="70" width="110"><br>
Sun, an Oracle Company<br>
<font color="#666666" face="Verdana, Arial, Helvetica, sans-serif"
size="2">Poonam Bajaj | Staff Engineer<br>
Phone: <a href="tel:+66937451">+66937451</a> | Mobile: <a
href="tel:+9844511366">+9844511366</a> <br>
JVM Sustaining Engineering<br>
| Bangalore </font>
<br>
<a href="http://www.oracle.com/commitment" target="_blank"><img
src="cid:part2.07040500.07010504@oracle.com" alt="Green Oracle"
align="absmiddle" border="0" height="28" width="44"></a>
<font color="#4b7d42" face="Verdana, Arial, Helvetica, sans-serif"
size="1">Oracle is committed to developing practices and products that
help protect the environment</font>
<!-- This signature was generated by the MyDesktop Oracle Business Signature utility version 3.8.5 --></p>
</div>
</body>
</html>