JVM flags: product -> manageable ?

[Srinivas Ramakrishna]

Yes, I am aware that a small subset of the options are already manageable or
product_rw, and the CR I referenced wanted to extend that set.
I am classifying the remaining options (but primarily the print/trace
ones, and primarily
related to GC) based on how we can modify them on-the-fly. I'll send
out the classification soon
and submit a patch of changes after i've done some light testing.

(PS: I am assuming the JEP question is for Staffan; I haven't quite
kept track of
them although I have seen some announced on these lists on and off. Don't know
if there's a single URL/point of entry into the JEP pool.)

- ramki

On Tue, Mar 13, 2012 at 12:29 AM, Kirk Pepperdine <kirk at kodewerk.com> wrote:
> 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.)
>>>
>>>
>>
>>
>
>