-XX:+ExplicitGCInvokesConcurrent logs not being parsed about gcviewer

[chewiebug]

Hi,

Thanks for mentioning this issue.
I can't reproduce the error messages you have copied above using -XX:+ExplicitGCInvokesConcurrent. So the gc log input would help (please use [email protected] to send the log).

Second question: What version of the JDK and what other options did you use to produce this log?

Regards, Jörg

[ecki]

The Message looks like
-XX:+PrintGCApplicationConcurrentTime and -XX:+PrintGCApplicationStoppedTime

BTW: in my tests the stopped time is often little bit higher than the GC durations, so might be worth parsing.

Bernd

[chewiebug]

Hi David

Bernd was right, the lines causing the parser exceptions are not caused
by -XX:+ExplicitGCInvokesConcurrent but by
-XX:+PrintGCApplicationConcurrentTime and
-XX:+PrintGCApplicationStoppedTime.

The explanation for the exceptions is easy: The gc algorithm is
concurrent, so sometimes the log output contains mixed lines which were
written at the same time by different threads and were not synchronized
before being written to the log file.

Example:
2012-08-23T04:32:38.692-0400: Application time: 0.0001990 seconds
154.700: [CMS-concurrent-sweep-start]

About half of the first line (without "Application time") is part of the
CMS-concurrent-sweep-start event, which finishes on the second line.
"Application time..." is a different event written in the middle of the
first event. The problem is, that the parser doesn't expect this mix of
lines and can't recover from it.

The solution is difficult, because there is no real pattern to these
mixed lines. I have implemented a solution for a few cases where
stop-the-world events are involved to improve accuracy of the GCViewer
graph, but the code tends to get tricky because of the lack of the patterns.

Since they don't appear too often in my experience, I consider this low
priority.

Regards, Jörg

[dferrao]

Ok. Thank you for taking a look.

Regards
David
On 29 Aug 2012 22:56, "chewiebug" [email protected] wrote:

Hi David

Bernd was right, the lines causing the parser exceptions are not caused
by -XX:+ExplicitGCInvokesConcurrent but by
-XX:+PrintGCApplicationConcurrentTime and
-XX:+PrintGCApplicationStoppedTime.

The explanation for the exceptions is easy: The gc algorithm is
concurrent, so sometimes the log output contains mixed lines which were
written at the same time by different threads and were not synchronized
before being written to the log file.

Example:
2012-08-23T04:32:38.692-0400: Application time: 0.0001990 seconds
154.700: [CMS-concurrent-sweep-start]

About half of the first line (without "Application time") is part of the
CMS-concurrent-sweep-start event, which finishes on the second line.
"Application time..." is a different event written in the middle of the
first event. The problem is, that the parser doesn't expect this mix of
lines and can't recover from it.

The solution is difficult, because there is no real pattern to these
mixed lines. I have implemented a solution for a few cases where
stop-the-world events are involved to improve accuracy of the GCViewer
graph, but the code tends to get tricky because of the lack of the
patterns.

Since they don't appear too often in my experience, I consider this low
priority.

Regards, Jörg

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/30#issuecomment-8133653.

[chewiebug]

I close this issue since I can't see a decent solution (see my above comment).