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

[Thomas Schatzl]

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