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

[Bengt Rutisson]

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 
> <mailto: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 
>> <mailto: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/
>>     <http://cr.openjdk.java.net/%7Ebrutisso/7166894/webrev.01/>
>>
>>     Thanks,
>>     Bengt
>>     _______________________________________________
>>     hotspot-gc-use mailing list
>>     hotspot-gc-use at openjdk.java.net
>>     <mailto: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 <mailto: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/88b42be9/attachment.html