JVM flags: product -> manageable ?

[Srinivas Ramakrishna]

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/20120312/f55ab923/attachment-0001.html