[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Enabling non product flags like "Verbose" in GC Code
From:       rednaxelafx () gmail ! com (Krystal Mok)
Date:       2011-08-26 5:16:25
Message-ID: CA+cQ+tSVHUpOZ6p0b4UiwXiWF7ZVku9upxocFkjQR0my6uDRQA () mail ! gmail ! com
[Download RAW message or body]

Comments inline below.

On Fri, Aug 26, 2011 at 4:37 AM, Ramki Ramakrishna <
y.s.ramakrishna at oracle.com> wrote:

> Hi Suraj --
> Either:
> (1) use a non-product build where the flag is available, OR
> (2) rebuild with Verbose declared a product flag (but you will have to deal
> with
> develop->product contagion which will require more such changes), OR
> (3) (probably the easiest in a specific product build) rebuild with Verbose
> changed to
> a new product flag of your choice for the specific sites where you
> want to print the info
> but want to retain the option of turning it off. Depending on where
> you do this, this
> may also cause a develop->product contagion, but it will be a more
> controlled burn, if
> i may be allowed to mix my metaphors.
> (..) anything else?
> The above are all one-off's for use in a specific build.


Yep, these are all valid. I've tried all of them.
(1) is good for those who's not interested in building a VM themselves. See
below for links for downloading a fastdebug build.
(2) is probably not the way one would want to go if the interest is only in
a specific part of the Verbose log. Turning Verbose from develop to product
almost always give you too much information, and it's hard to filter out
what you really want. Not to mention there's significant overhead to turing
all Verbose log on. Besides, part of the Verbose log printing is wrapped in
#ifndef PRODUCT, those are often really expensive and won't show up in a
product build even if Verbose is changed to a product flag.
(3) is what I've been using for investigating some of our GC issues in
production, It works great. But of course it's only for a specific purpose.

On Fri, Aug 26, 2011 at 4:37 AM, Ramki Ramakrishna <
y.s.ramakrishna at oracle.com> wrote:

> There may be good reason to protect some of these more useful messages with
> a product
> flag rather than with a develop flag. I recall Krystal Mok also mentioning
> something similar.
> Perhaps the community can work on what are the kinds of messages one might
> want to
> see in production (under control of a suitable manageable/product flag),
> and submit an OpenJDK
> patch with those changes (hopefully the performance impact of the check or
> enablement
> will be minor enough when these changes are for example communicating
> ergonomic
> decisions etc. -- this should of course be performance checked before a
> patch is submitted).


That's right, I've been working in this direction. I've temporarily added a
"PrintGCReason" production flag in my own build to print short messages of
the direct cause of a collection. Not done yet. It's not as simple as just
replacing some of the (PrintGCDetails && Verbose) log to using the new flag,
because there are cases where a collection is triggered but no verbose log
is printed. If I can get it to a point when it's mature enough, I'll submit
a patch to OpenJDK for open discussion. But that'll be after our OCA issue
is resolved.

(The "PrintGCReason" stuff is very different from HotSpot's existing notion
of "GCCause". The latter is too coarse and doesn't really provide enough
diagnostics of what's going on.)

I'm also experimenting on a new GC log parser that tries to parse some of
the output from the fancier flags. The original parser framework in GCHisto
doesn't seem to be powerful enough to do so, because it's stuck with regular
expressions but I think it needs a PDA to really get the job done. Wonder
how other guys are approaching this problem.

On Fri, Aug 26, 2011 at 4:37 AM, Ramki Ramakrishna <
y.s.ramakrishna at oracle.com> wrote:

> I'm also hoping that in the future some of these may be captured by the
> logging framework
> under construction. Those working on or planning to work on the logging
> framework may have
> more to add. So I am cc'ing the serviceability alias as well.


I'm really looking forward to this one. Please keep us updated on any plans
of a more uniform GC log format and the accompanying logging framework.

On Fri, Aug 26, 2011 at 5:34 AM, suraj puvvada <suraj.puvvada at gmail.com>
wrote:

> Thanks.
> Are the non-product builds available online to download ?


You can find some of the older builds on java.net, such as [1].
The fastdebug build for JDK 6 used to be published at [2]. But they're no
longer available. They used to be removed (or hidden? I don't know) once an
FCS is released, though.

Making your own build of the HotSpot VM isn't hard. Charles Nutter was kind
enough to share his build script recently, following something similar may
be a good starting point [3].

Regards,
Kris Mok

[1]: http://download.java.net/jdk6/6u25/promoted/b03/binaries/
[2]: http://download.java.net/jdk6/binaries/
[3]: http://mail.openjdk.java.net/pipermail/mlvm-dev/2011-August/003775.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20110826/2e796b0c/attachment.html \



[prev in list] [next in list] [prev in thread] [next in thread]