RFR (s): 8026849 - Fix typos in the GC code, part 2

[Coleen Phillimore]

Hi Thomas,

I wasn't suggesting never adding and improving the gc log output.   
Removing this comma seems not worth breaking Kirk's (or anyone's) gc log 
parser.   If you have to make substantive or content changes, these 
should be made, certainly with care.   I think this particular change 
doesn't rate breaking existing parsers.

Coleen

On 1/29/14 4:19 PM, Thomas Schatzl wrote:
> Hi Coleen,
>
> On Wed, 2014-01-29 at 11:04 -0500, Coleen Phillimore wrote:
>> I'm a Reviewer and I don't think you should fix the comma if tools
>> rely on it.  Just fix the typos in the asserts.
>    I am a bit torn about this statement: does that mean we should not
> change the log output at all because some parsers out there cannot deal
> with any changes?
>
> While I think it is a good idea to keep compatibility, there should be
> boundaries on that.
> (There is actually a separate CR for that particular issue, JDK-8023899,
> for months that should be fixed separately).
>
> Like Kirk, I am almost daily studying and analyzing gc logs (and for
> some reason the tools I use do not care about this at all), and this
> reasoning would definitely stop my efforts to make the log more useful
> for me.
>
> Point in case, I have a few changes that give detailed information about
> the "Ext root scan" phase, the reference processing phase, and the one
> or other additional phase that has not been measured before.
>
> These additional log messages have helped me a lot analyzing issues in
> the last months.
>
> I would, if possible have that all with the respective improvements in
> 8u20 (as time permits), since I think these messages will help me a lot
> in diagnosing issues and answering questions in the future.
>
> While I am not really insistent on the extra comma, there should be some
> way forward to introduce changes and additions. Your blanket rejection
> statement somewhat discourages me to add stuff to the hotspot gc log, if
> every little change, and something like a clear bug (Imo, and I'm sure
> there are people disagreeing with me, instead of writing a parser to
> require something obviously a typo, it should be reported and fixed
> asap, but that's another issue) even gets shot down immediately.
>
> Also, for some reason, the people I worked with when implementing these
> solutions were not bothered by these changes at all btw, just tweaked
> their parsers (if they did anything) without mentioning. They are
> clearly parsing the gc logs too for statistics.
>
> Making changes to Hotspot GC logs should not be burdened too much. At
> least I, and the rest of the GC team needs them on a frequent basis.
> They should follow the functionality naturally, without needing
> backwards compatibility workarounds.
>
> Mind you, I am not advocating radical changes, just additions and
> improvements that may definitely break some badly written parsers: e.g.
> one phase gets parallelized or so, now gets the usual treatment showing
> overall timings and statistics etc.
>
> I do not see a real difference to the current situation with the
> TraceCPUTime than with my fixes. Both potentially break parsers because
> of additional/changed content.
>
> What do you suggest? Should we wait until JDK 9 (2015)? 10 (201X)? to
> get useful GC logs or minor typos in the logs fixed? Should we tell our
> users even longer: well, I do not have a clue what's the actual problem
> because the gc logs are inadequate [we know and want to change stuff but
> we cannot]?
>
> In the extreme case, shouldn't we just keep them around as legacy
> baggage, possibly moving to JFR events because we cannot change anything
> in the logs because of some parsers?
>
> Thanks for your consideration,
>    Thomas
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20140129/8f75a8d8/attachment.html