Feedback requested: HotSpot GC logging improvements
ycraig at cysystems.com
Thu May 6 20:47:17 UTC 2010
- No I am not attached to the old -verbosegc output.
- I would also think that having the time stamps should be default.
- Having a reliable parser would definitely be a welcome addition.
- We handle our own gc log rotation, but if you were to provide it I
would prefer the zero padded sequence number.
- Not one of those folks.
On May 6, 2010, at 3:32 PM, Tony Printezis wrote:
> 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
> some time. However we haven't had the resources to spend on it. We
> 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
> I strongly believe that maintaining two GC log formats is
> counter-productive, especially given that the current -verbosegc
> 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
> be able to parse the -verbosegc output). The new output will not be
> -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
> 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
> 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
> size, we cannot easily cycle through the log using the same file (I'd
> rather not have to overwrite existing records). Our current proposal
> 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
> (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
> oldest. So, in the above example, if N == 3, when we create foo.
> 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
> the same effect.
> Another (related) request has been to maybe append the GC log file
> with the pid of the JVM that's generating it. Maybe we don't want to
> 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:
> 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
> 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
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
More information about the hotspot-gc-dev