<br><font size=2 face="sans-serif">Evening</font>
<br>
<br><font size=2 face="sans-serif">we currently manage the log overwriting
issue by mv'ing the last gc.log to gc.log.<timestamp when the new jvm
one starts>, if you're going to roll the logs then I would prefer a
meaningful suffix rather than just a counter. </font>
<br>
<br><font size=2 face="sans-serif">I second the idea that datestamps should
be the default.</font>
<br>
<br><font size=2 face="sans-serif">I think a unified, easily parseable
but still readable output would be great though wouldn't you still need
a verbose output that is specific to each collector in order to provide
a "debug" level of detail?</font>
<br>
<br><font size=2 face="sans-serif">Cheers</font>
<br><font size=2 face="sans-serif">Matt</font>
<br><font size=2 face="sans-serif"><br>
Matt Khan<br>
--------------------------------------------------<br>
GFFX Auto Trading<br>
Deutsche Bank, London<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Tony Printezis <tony.printezis@oracle.com></b>
</font>
<br><font size=1 face="sans-serif">Sent by: hotspot-gc-use-bounces@openjdk.java.net</font>
<p><font size=1 face="sans-serif">06/05/2010 20:32</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">hotspot-gc-use@openjdk.java.net</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Feedback requested: HotSpot GC logging
improvements</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2>Hi all,<br>
<br>
We would like your input on some changes to HotSpot's GC logging that we
<br>
have been discussing. We have been wanting to improve our GC logging for
<br>
some time. However we haven't had the resources to spend on it. We don't
<br>
know when we'll get to it, but we'd still like to get some feedback on
<br>
our plans.<br>
<br>
The changes fall into two categories.<br>
<br>
<br>
A. Unification and improvement of -verbosegc / -XX:+PrintGCDetails output.<br>
<br>
I strongly believe that maintaining two GC log formats is <br>
counter-productive, especially given that the current -verbosegc format
<br>
is unhelpful in many ways (i.e., lacks a lot of helpful information). <br>
So, we would like to unify the two into one, with maybe <br>
-XX:+PrintGCDetails generating a superset of what -verbosegc would <br>
generate (so that a parser for the -XX:+PrintGCDetails output will also
<br>
be able to parse the -verbosegc output). The new output will not be what
<br>
-XX:+PrintGCDetails generates today but something that can be reliably
<br>
parsed and it is also reasonably human-readable (so, no xml and no <br>
space/tab-separated formats). Additionally, we're proposing to enable <br>
-XX:+PrintGCTimeStamps by default (in fact, we'll probably deprecate and
<br>
ignore that option, I can't believe that users will really not want a <br>
time stamp per GC log record). We'll leave -XX:+PrintGCDateStamps to be
<br>
optional though.<br>
<br>
Specific questions:<br>
<br>
- Is anyone really attached to the old -verbosegc output?<br>
- Would anyone really hate having time stamps by default?<br>
- I know that a lot of folks have their own parsers for our current GC
<br>
log formats. Would you be happy if we provided you with a (reliable!) <br>
parser for the new format in Java that you can easily adapt?<br>
<br>
<br>
B. Introducing "cyclic" GC logs.<br>
<br>
This is something that a lot of folks have asked for given that they <br>
were concerned with the GC logs getting very large (a 1TB disk is $85 <br>
these days, but anyway...). Given that each GC log record is of variable
<br>
size, we cannot easily cycle through the log using the same file (I'd <br>
rather not have to overwrite existing records). Our current proposal is
<br>
for the user to specify a file number N and a size target S for each <br>
file. For a given GC log -Xloggc:foo, HotSpot will generate<br>
<br>
foo.00000001<br>
foo.00000002<br>
foo.00000003<br>
etc.<br>
<br>
(we'll create a new file as soon as the size of the one we are writing
<br>
to exceeds S, so each file will be slightly larger than S but it will be
<br>
helpful not to split individual log records between two files)<br>
<br>
When we create a new file, if we have more than N files we'll delete the
<br>
oldest. So, in the above example, if N == 3, when we create foo.00000004
<br>
we'll delete foo.00000001.<br>
<br>
Note that in the above scheme, the logs are not really "cyclic"
but, <br>
instead, we're pruning the oldest records every now and then, which has
<br>
the same effect.<br>
<br>
Another (related) request has been to maybe append the GC log file name
<br>
with the pid of the JVM that's generating it. Maybe we don't want to do
<br>
this by default. But, would people find it helpful if we provide a new
<br>
cmd line parameter to do that? So, for the above example and assuming <br>
that the JVM's pid is 1234, the GC log file(s) will be either:<br>
<br>
foo.1234<br>
<br>
or<br>
<br>
foo.1234.00000001<br>
foo.1234.00000002<br>
foo.1234.00000003<br>
etc.<br>
<br>
Specific questions:<br>
<br>
- Would people really hate it if HotSpot starts appending the GC log <br>
file name with a (zero-padded) sequence number? Maybe if N == 1 (the <br>
default), HotSpot will skip the sequence number and ignore S, i.e., <br>
behave as it does today.<br>
- To the people who have been asking for cyclic GC logs: is the sequence
<br>
number scheme above good enough?<br>
<br>
<br>
Thanks in advance for your feedback,<br>
<br>
Tony, HotSpot GC Group<br>
<br>
_______________________________________________<br>
hotspot-gc-use mailing list<br>
hotspot-gc-use@openjdk.java.net<br>
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use<br>
</font></tt>
<br>
<br>
<br>
<span style="font-family:sans-serif,helvetica; font-size:10pt; color:#000000">---<br>
<br>
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.<br>
<br>
Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures.</span><br>