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

[Kirk Pepperdine]

Hi,

I’ve not suggested that logs shouldn’t change to add new records that offer better diagnostic information nor have I suggested that these spelling mistakes be left as is (though I’m surprised they made it past a code review). I can certainly tweak my parser for the change in the log files also but the question is, what value does that little comma bring to the table? Prior to this we had a missing s on sec and we have sec, secs, and seconds being used.. Any of them are good but why do we have all three, well two at the moment but 3 if you have to work with previous releases. And if we travel back there are more instances where non-substantive changes to formats have been made. All I’m suggesting is that people resist these types of changes.

Regards,
Kirk

On Jan 29, 2014, at 10:19 PM, Thomas Schatzl <thomas.schatzl at oracle.com> 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
> 
>