Will parsers break if we start logging the GC cause as part of the PrintGC logging?

[Vitaly Davidovich]

Hi Bengt,

Sounds good - looking forward to seeing what you come up with.

Let me also echo others that this is a great addition, so thanks for doing
it.

Thanks

Sent from my phone
On May 8, 2012 6:38 AM, "Bengt Rutisson" <bengt.rutisson at oracle.com> wrote:

>
> Thanks for the feedback everyone!
>
> I think I'll do as Ramki suggested. Add the GC cause to all collectors,
> but add a switch for users to turn it off. I am not too happy about adding
> another command line option, but is seems more consistent to do the change
> for all collectors.
>
> I'll do the changes and post a new webrev on the hotspot-gc-dev list.
>
> Vitaly, I have been experimenting a bit with your suggestion of a stack
> local object to do the string concatenation. This will be even more
> valuable if I do the change for all collectors, so I'll probably include
> that in the new webrev as well.
>
> Thanks,
> Bengt
>
> On 2012-05-08 07:52, Srinivas Ramakrishna wrote:
>
> I'd tend to agree with Vitaly, since that puts the choice in the hands of
> the users, at least until they figure out how to fix their parsers... You
> could enable the option by default, but the existence of the option allows
> a user to switch off the feature if they just can't deal with it. That
> said, as a user I wouldn't lose any sleep over it... We'll just fix our
> parsers if/ when the change comes along.
>
>  I'd strongly suggest making the change for all collectors, rather than
> for only a small subset...
>
>  Thanks for this addition, it'll be generally useful.... And I'd say have
> it for each collection, not just full collections...
>
>  -- Ramki
>
> Sent from my iPhone
>
> On May 7, 2012, at 2:24 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>
>   Hi Be! ngt,
>
> Another option would be to enable the extra logging/new format via a VM
> argument? I know there are already tons of them so this is probably
> undesirable, but may provide at least a transition period for customers to
> upgrade their parsers.
>
> Sent from my phone
> On May 7, 2012 5:19 PM, "Bengt Rutisson" <bengt.rutisson at oracle.com>
> wrote:
>
>>
>> Hi all,
>>
>> I have a webrev out for a change that will add the GC cause to all "Full
>> GC logging". See:
>>
>> http://permalink.gmane.org/gmane.comp.java.openjdk.hotspot.gc.devel/4527
>>
>> The extra information was intentionally just added to full GCs since
>> this logging already had information for System.gc() calls so we figured
>> that any parsers out there would have to handle this information anyway.
>>
>> It was requested to add the information about the GC cause also to CMS
>> collections. If I start down that path I think I could just as well add
>> the GC cause to all GC logging. If we break any parsers we will probably
>> break them already when we add the cause to CMS GCs.
>>
>> Not sure what the best way to handle this is. Some suggestions:
>>
>> (1) Only add cause to Full GCs (as in my change now)
>> (2) Only add cause to Full GCs and CMS GCs (as I think is what was
>> suggested)
>> (3) Add cause to all GCs (probably the proper but kind of risky way)
>> (4) Only do (1) but file CRs for (2) and (3)
>>
>> Any thoughts? It is really a choice between getting interesting
>> information and risking breaking existing GC log parsers.
>>
>> Here is the latest webrev:
>> http://cr.openjdk.java.net/~brutisso/7166894/webrev.01/
>>
>> Thanks,
>> Bengt
>> _______________________________________________
>> hotspot-gc-use mailing list
>> hotspot-gc-use at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>>
>   _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20120508/aa4b6ad0/attachment-0001.html