8000 Problem with J9 verbose GC logfile · Issue #40 · chewiebug/GCViewer · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Problem with J9 verbose 8000 GC logfile #40

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
ecki opened this issue Oct 8, 2012 · 6 comments
Closed

Problem with J9 verbose GC logfile #40

ecki opened this issue Oct 8, 2012 · 6 comments
Labels
bug
Milestone
1.32

Comments

@ecki
Copy link
Contributor
ecki commented Oct 8, 2012

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
Copy link
Contributor Author
ecki commented Oct 11, 2012

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
Copy link
Owner

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
Copy link
Contributor Author
ecki commented Oct 12, 2012

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 referenced this issue Feb 8, 2013
@sfraser
Working on patch to handle parsing IBM GC Logs that are for huge heap…
c03fbf1 
…s (like 290GB and larger).

This patch fixes an issue where GCViewer could not open the logs at all due to NUmberFormatExceptions
(assumptions that heap sizes could fit in int data type), and also some display defects for showing
info on such large heaps.

Mostly changing ints to longs, some formatting changes, and some class name changes. Still trying to figure out what
amount freed shows up negative - I am wondering if the IBM format logs are not being parsed correctly.
@chewiebug
Copy link
Owner

Hi Bernd,

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

Regards, Jörg

@ecki
Copy link
Contributor Author
ecki commented Feb 17, 2013

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
Copy link
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
1.32
Development

No branches or pull requests
2 participants
@ecki @chewiebug
0