gc.log with faulty ParNew

[Krystal Mok]

Hi Charles,

I guess if the log in TraceTime (hotspot/src/share/vm/runtime/timer.cpp) is
printed out as a whole in TraceTime's destructor, then the log would look
more "intact", but the ordering of events in the log would have changed.

Suppose TraceTime is modified this way, the GC log in your example,
starting from line 14, would become:

0.782: [GC 0.782: [ParNew: 17039K->1K(19136K), 0.0009367 secs]
55740K->38701K(83008K), 0.0009757 secs] [Times: user=0.00 sys=0.00,
real=0.00 secs]
0.883: [CMS-concurrent-abortable-preclean: 0.001/0.146 secs] [Times:
user=0.14 sys=0.01, real=0.15 secs]
0.867: [GC 0.867: [ParNew: 17025K->2110K(19136K), 0.0540174 secs]
55725K->48933K(83008K), 0.0541048 secs] [Times: user=0.08 sys=0.02,
real=0.06 secs]

Notice that because the ParNew collection ended later than the
abortable-preclean phase, its log comes after, but it started earlier so
now the timestamp ordering now looks weird. If that's okay with everyone,
it'd be an easy fix.

Regards,
Kris Mok

On Tue, Nov 8, 2011 at 5:49 AM, Charles K Pepperdine <kirk at kodewerk.com>wrote:

> Hi all,
>
> Line 15 of this log file has a ParNew record split by the end or an
> abortable-preclean. Is there a way to prevent the gc log records from being
> corrupted in this way? This is not the only place it happens and it makes
> an already impossible task of scanning these things much harder.
>
> Regards,
> Kirk
>
>
> Begin forwarded message:
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20111108/f272c0c4/attachment.htm>