Feedback requested: HotSpot GC logging improvements

Thu May 6 13:20:35 PDT 2010

Perhaps the logfile suffix could be parametrized (sequence, datestamp,  
etc)?
GCTimeStamps efinitely should be definitely be the default because as  
previously pointed out, post-mortem without 'em is painful.
For more debug detail per collector one could use PrintHeapAtGC or  
similar couldn't one?
I always had a weakness for the simplicity of HP's format - one line,  
space separated with time, date, cause and sizes of each generation.  
Super easy to parse and even eye-scan. That being said, now that we  
have jVisualVM with snapshots and everything the GCDetails output is  
complete and practical as well.
Cheers,
Fini

Sent from Fino's iPhone 3GS

Michael Finocchiaro
Mobile +6 85 46 07 62
http://mfinocchiaro.wordpress.com

On 6 mai 2010, at 22:01, Matt Khan <matt.khan at db.com> wrote:

>
> Evening
>
> 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.
>
> I second the idea that datestamps should be the default.
>
> 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?
>
> Cheers
> Matt
>
> Matt Khan
> --------------------------------------------------
> GFFX Auto Trading
> Deutsche Bank, London
>
>
>
> Tony Printezis <tony.printezis at oracle.com>
> Sent by: hotspot-gc-use-bounces at openjdk.java.net
> 06/05/2010 20:32
>
> To
> hotspot-gc-use at openjdk.java.net
> cc
> 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 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.
>
> Please refer to http://www.db.com/en/content/eu_disclosures.htm for  
> additional EU corporate and regulatory disclosures.
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20100506/7cd97d1c/attachment.html 