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

[Srinivas Ramakrishna]

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 Bengt,
> 
> 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/20120507/8877e874/attachment-0001.html