JVM flags: product -> manageable ?

[Staffan Larsen]

Here is the list of JEPs: http://jep.openjdk.org/jeps/0

The logging JEP has not been published (or written...) yet. 

/Staffan

On 13 mar 2012, at 17:31, Srinivas Ramakrishna <ysr1729 at gmail.com> wrote:

> 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.)
>>>> 
>>>> 
>>> 
>>> 
>> 
>>