Problem with J9 verbose GC logfile

[ecki]

The following GC logfile is generated from IBM Java 6 SR5 on AIX, it has two main problems:

• first of all the tag is missing because this was a file from running instance. I can fix this by hand adding the closing element however I think the parser could just ignore the exception
• secondly some of the numbers are outside of the integer range and therefore create a number format exception. A quick hack to replace the Integer.parseInteger with parseLong helped with the parsing errors, but the resulting chart did not look right.

https://mft.seeburger.de/portal-seefx/~public/ca4ab842-2ff5-457c-b6b6-f5e458e3adf0?download

[ecki]

In this branch I have a prelimiary fix, it will parse the numbers as longs and it ignores the SAP parser exception with a different (language independent) method. However I think both is not the final version. The chart produced from above logfile does also not look right.

https://github.com/ecki/GCViewer/tree/topic-j9logfix

[chewiebug]

Now at least something is displayed. Thanks for looking into this problem.

I agree with you, that the chart does not look right. GCViewer assumes,
that all parsed events were FULL GCs. That is probably not right. The
README https://github.com/chewiebug/GCViewer/blob/master/README file
mentions, that the IBM logfiles contain much more information than is
parsed. IBM GMCV
http://www.ibm.com/developerworks/java/jdk/tools/gcmv/ is much better
in this case.

Regards, Jörg

Am 11.10.2012 03:50, schrieb Bernd:

In this branch I have a prelimiary fix, it will parse the numbers as
longs and it ignores the SAP parser exception with a different
(language independent) method. However I think both is not the final
version. The chart produced from above logfile does also not look right.

https://github.com/ecki/GCViewer/tree/topic-j9logfix

—
Reply to this email directly or view it on GitHub
#40 (comment).

[ecki]

Yes there is also a comment in the code that it only works for one policy (only looking at the allocation failure events). I try to work on that some more as I like the gcviewer statistics more than the GCMV (especially since it is somewhat only a reporting tool in ISA anymore).

[chewiebug]

Hi Bernd,

May I merge your preliminary fix? There is an increasing number of users who will profit from it.

Regards, Jörg

[ecki]

I have rebased my topic-j9fix, but I think the changes to LongData in the above commit from @sfraser looks better (I somewhat not sure where that commit was commited... )

[chewiebug]

I have pushed a fix based on your branch to allow those large heap numbers including correct conversion to KB when storing the event data in a GCEvent class. While coding the fix I finally understood, why @sfraser's commit looked better to you - I believe that the main confusion was centered around IBMs usage of Bytes in the log file while GCViewer stores KB in it's data model.

I close this issue since I believe that the problem for which you opened the issue is fixed now. The IBM logs still contain much more information than GCViewer can parse. Please open another issue if you work on improving GCViewers level of details that is parsed from one of those logs.

As always: If the fix doesn't solve the issue, please reopen it.

Regards, Jörg