gc.log with faulty ParNew

[Charles K Pepperdine]

Dude,

IMHO it is much much easier for me to sort on the timestamp than it is to reconstruct broken logging records. And, there are a number of other cases where the same thing happens. I'm all for the out of order fix but I wonder if others with tools will be so forgiving. That said, I'd vote +1 for this fix.

Regards,
Kirk

On Nov 8, 2011, at 4:18 AM, Krystal Mok wrote:

> 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/60019294/attachment.htm>