JVM flags: product -> manageable ?

[Kirk Pepperdine]

Hi Ramki,

As you're most likely aware, you can turn on basic GC logging on the fly. From my look at GC logging code I've not seen anything that would preclude turning on other options that would print more information. True, it might cause the logs to be corrupted in the first cycle but since GC log analysis is akin to pool chemistry. It's typically performed with 100s of records, a few bad ones isn't going aren't going to change much and an extra scoop isn't going to make a difference w.r.t. conclusions.

Has the JEP for gc logging been released? I've not seen it being discussed and I'm keenly interested in this. In fact, my plan was to spend some time in April/May digging into it.

Regards,
Kirk

On 2012-03-12, at 9:34 PM, Srinivas Ramakrishna wrote:

> Good point. Typically the way this is managed in GC code is to take a snapshot of the options in the prolog and to use them in the GC proper.
> (I believe there is code in CMS that does stuff like this because of the interaction between heap verification and
> class unoading, and i can't recall which if either of these can be manageable (ah. i know -- this is because
> we can ask for verification to switch on at a specific GC and turn off after a specific GC or something like that.)
> I believe the same applies to some of the "dump" options as well.
> 
> You are right though that if the flag involves communication of data across a specific temporal point (in general),
> then one would want to take a snapshot at the right place. Typically (but not always) safepoints have served as such
> a point. But this would need an audit on a case-by-case basis.
> 
> Thanks for pointing this out! I believe this is still worth doing in the shorter term if possible, and I am happy to
> help if asked (my OCA is being processed i believe).
> 
> -- ramki
> 
> On Mon, Mar 12, 2012 at 1:15 PM, Staffan Larsen <staffan.larsen at oracle.com> wrote:
> I don't know how reliable it would be to just make those flags manageable. For example, the GC code may have code paths that set up information for logging at an early point in time only if logging is enabled, and depend on this information being available later. Turning on logging mid-flight could cause problems here. I don't know if this is true, though, but it would have to be examined when making flags manageable.
> 
> /Staffan
> 
> On 12 mar 2012, at 20:47, Srinivas Ramakrishna wrote:
> 
>> Thanks for the prompt response, Staffan!
>> 
>> One question is re support of existing flags (in particular GC flags) and their toggling via the
>> existing jmap interface. I am sure that will be detailed in the JEP in progress.
>> In the much shorter term, I was wondering if the step of changing the trivially changeable
>> GC-logging flags could be accomplished, since that would really involve a quick audit and some
>> really quick performance numbers to ascertain that something unexpected did not happen,
>> so should be relatively lightweight....
>> 
>> thoughts/comments?
>> -- ramki
>> 
>> On Mon, Mar 12, 2012 at 12:40 PM, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>> Maybe a little off-topic, but there are plans to revise JVM logging as a whole. As part of this, it is planned that logging can be turned on and off at runtime. A JEP is in progress.
>> 
>> Thanks,
>> /Staffan
>> 
>> 
>> On 12 mar 2012, at 20:26, Srinivas Ramakrishna wrote:
>> 
>>> 
>>> Hi all --
>>> 
>>> What's the plan for:
>>> 
>>> 6950384 We should make some / all GC logging parameters manageable
>>> 
>>> Is this on the cards for the near-future?
>>> 
>>> I'd be very interested to see this happen because it really improves the JVM/GC
>>> serviceability/obsevability story (at least from a low-level perspective).
>>> 
>>> thanks for any info!
>>> -- ramki
>>> 
>>> PS: Aside: the CR is specific to hotspot/gc -- are there corresponding plans for
>>> flags from any of the other components within the JVM besides GC?
>>> (My current interest is only in some of the GC logging flags, so this is
>>> really more a curiosity wrt other parts of the JVM, rather than an explicit
>>> interest at this time in those other flags.)
>> 
>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120313/84f5b756/attachment.html