Proposed changes to the GC logging flags

Tony Printezis tony.printezis at sun.com
Fri Apr 4 09:43:01 PDT 2008



James Nichols wrote:
> I'd rather not have the format of the log changed, but simplifying the 
> arguments would be great.  Isn't that the only change being proposed?
We're asking feedback on both.
> Doesn't everyone have a Perl script that they use to pull out the 
> stuff from the log that's relevant and put it in gnuplot or Excel or 
> something?
If we can provide you with a Java library that parses whatever format we 
come up with and allows you to access the data from Java, in a sense 
shielding you from GC log format changes, would that be a reasonable 
compromise?

Tony
> On Fri, Apr 4, 2008 at 3:46 AM, Michael Finocchiaro 
> <michael.finocchiaro at gmail.com <mailto:michael.finocchiaro at gmail.com>> 
> wrote:
>
>     That is good idea to make PGCTS the default with PGCD and I also
>     agree that the TraceClassUnloading is annoying in a gc log.
>
>     I would propose that you look at HP's JVM GC log format as
>     something far easier to parse than the current format.
>
>     http://docs.hp.com/en/5992-1918/ch01s25.html
>
>     or perhaps the jstatd format.
>
>     After about 5 or 6 years I can almost eyeball the current file
>     format but a numeric based, space or comma-separated list of the
>     GC cause and the memory space allocations would be a lot easier
>     for post-mortem diagnosis and tuning. And, at least in the HP
>     case, the overhead is very minimal (you get almost the same amount
>     of detail as from -XX:+PrintTenuringDistribution in a single
>     line)...and since there still is not a robust and easy-to-use
>     equivalent of HPjmeter (disclosure - I worked for 10 years for HP)
>     for analyzing the JavaSoft HotSpot JVMs, this would be an improvement.
>
>     My 2 cents,
>     Fino
>
>
>     On Thu, Apr 3, 2008 at 11:22 PM, Tony Printezis
>     <tony.printezis at sun.com <mailto:tony.printezis at sun.com>> wrote:
>
>         We're proposing a few small changes (and on significant one)
>         to the way
>         the GC logging flags work:
>
>         a) When +PrintGCDetails is set, +PrintGCTimeStamps should be
>         set by
>         default (currently, it has to be set explicitly; what we've
>         found is
>         that it's always more useful to have the time stamps in a GC
>         log when
>         analyzing it)
>         b) When -XXloggc: is set, +PrintGCDetails and
>         +PrintGCTimeStamps are set
>         automatically (instead of -verbosegc and +PrintGCTimeStamps)
>         (again, for
>         us, it's always more useful to have the more detailed
>         +PrintGCDetails
>         output in the log when analyzing it)
>         c) When -verbosegc, +PrintGCDetails, or -Xloggc: are set,
>         +TraceClassUnloading is _not_ automatically set, as it is now (it
>         polutes the output a bit during Full GCs)
>
>         Notice that, for the above, you'll still be able to get the
>         old behavior
>         by setting / unsetting some flags; we're just trying to set more
>         sensible defaults.
>
>         The more significant proposal:
>
>         d) Eliminate the -verbosegc format in favor of the (more
>         detailed and
>         more useful, though less concise) +PrintGCDetails format. Do
>         people
>         still heavily use and rely on the -verbosegc format in a way that
>         migration to the +PrintGCDetails format will be difficult?
>
>         Your thoughts and feedback on the above will be appreciated.
>         Thank you,
>
>         Tony, HS GC Group
>
>         --
>         ----------------------------------------------------------------------
>         | Tony Printezis, Staff Engineer    | Sun Microsystems Inc.  
>                |
>         |                                   | MS BUR02-311            
>               |
>         | e-mail: tony.printezis at sun.com
>         <mailto:tony.printezis at sun.com>    | 35 Network Drive        
>               |
>         | office: +1 781 442 0998 (x20998)  | Burlington,
>         MA01803-0902, USA  |
>         ----------------------------------------------------------------------
>         e-mail client: Thunderbird (Solaris)
>
>
>         _______________________________________________
>         hotspot-gc-use mailing list
>         hotspot-gc-use at openjdk.java.net
>         <mailto:hotspot-gc-use at openjdk.java.net>
>         http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>
>
>
>
>     -- 
>     Michael Finocchiaro
>     michael.finocchiaro at gmail.com <mailto:michael.finocchiaro at gmail.com>
>     Mobile Telephone: +33 6 67 90 64 39
>     MSN: le_fino at hotmail.com <mailto:le_fino at hotmail.com>
>     _______________________________________________
>     hotspot-gc-use mailing list
>     hotspot-gc-use at openjdk.java.net
>     <mailto:hotspot-gc-use at openjdk.java.net>
>     http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>
>

-- 
----------------------------------------------------------------------
| Tony Printezis, Staff Engineer    | Sun Microsystems Inc.          |
|                                   | MS BUR02-311                   |
| e-mail: tony.printezis at sun.com    | 35 Network Drive               |
| office: +1 781 442 0998 (x20998)  | Burlington, MA01803-0902, USA  |
----------------------------------------------------------------------
e-mail client: Thunderbird (Solaris)


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



More information about the hotspot-gc-dev mailing list