Feedback requested: HotSpot GC logging improvements

[jeff.lloyd at algorithmics.com]

Hi Tony,

I'm in favour of item A.  I'm not attached to the old format, and I'd
like to see time stamps as the default.

I also like item B.

Can I make a suggestion for item B?  Have you noticed everyone who posts
their GC log file additionally has to include in their email the gc
config options that they think they used for that particular run?  In
our application we prefix _every_ "cyclic" log file with the config
options used to start the app.  It makes reporting problems easier and
we can see which options the client used by looking at the top of the
log file instead of having to ask the client for what they thought they
used.

Jeff

-----Original Message-----
From: hotspot-gc-use-bounces at openjdk.java.net
[mailto:hotspot-gc-use-bounces at openjdk.java.net] On Behalf Of Tony
Printezis
Sent: Thursday, May 06, 2010 3:33 PM
To: hotspot-gc-use at openjdk.java.net
Subject: Feedback requested: HotSpot GC logging improvements

Hi all,

We would like your input on some changes to HotSpot's GC logging that we

have been discussing. We have been wanting to improve our GC logging for

some time. However we haven't had the resources to spend on it. We don't

know when we'll get to it, but we'd still like to get some feedback on 
our plans.

The changes fall into two categories.


A. Unification and improvement of -verbosegc / -XX:+PrintGCDetails
output.

I strongly believe that maintaining two GC log formats is 
counter-productive, especially given that the current -verbosegc format 
is unhelpful in many ways (i.e., lacks a lot of helpful information). 
So, we would like to unify the two into one, with maybe 
-XX:+PrintGCDetails generating a superset of what -verbosegc would 
generate (so that a parser for the -XX:+PrintGCDetails output will also 
be able to parse the -verbosegc output). The new output will not be what

-XX:+PrintGCDetails generates today but something that can be reliably 
parsed and it is also reasonably human-readable (so, no xml and no 
space/tab-separated formats). Additionally, we're proposing to enable 
-XX:+PrintGCTimeStamps by default (in fact, we'll probably deprecate and

ignore that option, I can't believe that users will really not want a 
time stamp per GC log record). We'll leave -XX:+PrintGCDateStamps to be 
optional though.

Specific questions:

- Is anyone really attached to the old -verbosegc output?
- Would anyone really hate having time stamps by default?
- I know that a lot of folks have their own parsers for our current GC 
log formats. Would you be happy if we provided you with a (reliable!) 
parser for the new format in Java that you can easily adapt?


B. Introducing "cyclic" GC logs.

This is something that a lot of folks have asked for given that they 
were concerned with the GC logs getting very large (a 1TB disk is $85 
these days, but anyway...). Given that each GC log record is of variable

size, we cannot easily cycle through the log using the same file (I'd 
rather not have to overwrite existing records). Our current proposal is 
for the user to specify a file number N and a size target S for each 
file. For a given GC log -Xloggc:foo, HotSpot will generate

foo.00000001
foo.00000002
foo.00000003
etc.

(we'll create a new file as soon as the size of the one we are writing 
to exceeds S, so each file will be slightly larger than S but it will be

helpful not to split individual log records between two files)

When we create a new file, if we have more than N files we'll delete the

oldest. So, in the above example, if N == 3, when we create foo.00000004

we'll delete foo.00000001.

Note that in the above scheme, the logs are not really "cyclic" but, 
instead, we're pruning the oldest records every now and then, which has 
the same effect.

Another (related) request has been to maybe append the GC log file name 
with the pid of the JVM that's generating it. Maybe we don't want to do 
this by default. But, would people find it helpful if we provide a new 
cmd line parameter to do that? So, for the above example and assuming 
that the JVM's pid is 1234, the GC log file(s) will be either:

foo.1234

or

foo.1234.00000001
foo.1234.00000002
foo.1234.00000003
etc.

Specific questions:

- Would people really hate it if HotSpot starts appending the GC log 
file name with a (zero-padded) sequence number? Maybe if N == 1 (the 
default), HotSpot will skip the sequence number and ignore S, i.e., 
behave as it does today.
- To the people who have been asking for cyclic GC logs: is the sequence

number scheme above good enough?


Thanks in advance for your feedback,

Tony, HotSpot GC Group

_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use

 
--------------------------------------------------------------------------
This email and any files transmitted with it are confidential and proprietary to Algorithmics Incorporated and its affiliates ("Algorithmics"). If received in error, use is prohibited. Please destroy, and notify sender. Sender does not waive confidentiality or privilege. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. Algorithmics does not accept liability for any errors or omissions. Any commitment intended to bind Algorithmics must be reduced to writing and signed by an authorized signatory.
--------------------------------------------------------------------------