Evaluating JVM Heap Dumps

Despite running JVM supposedly being rock-solid and stable I see enough JVM who cant take the load, most likely to non-optimal settings, throwing heap dumps.
A while ago I struggled to open Thread Dumps I can open heap dumps with VisualVM (Version 1.3.7 at the time of writing)

VisualVM

VisualVM

Heap Dump File

Heap Dump File

Beware, with significant heap dump files (in my sample 700MB) it can take quite a while to open or review the results. Open thread dump list took a good 10 minutes.

Long Processing Times

Long Processing Times

Advertisements

Talk back and Feedback

As an IT company you know feedback is vital and can be crucial to maintain a level of quality. Either you collect feedback a) directly from your users (person to person, email, phone, ticket system,..) or b) let the deployed software talk to you directly.  How many time some piece of software crashed or did something wrong and you – as in case a) – dont bother to do anything and just restart the application and continue your work ? Many times I guess, only if the software really does not wok anymore, we would feedback and complain. So all these valuable small (and lost) incidents that appear isolated to a enduser would help to increase the quality of the software if we just would feedback (manually).

But most of us are also not happy if the software talks back to its vendor directly because we either fear it would transfer personal data or just would tell the vendor that you are using some pirated version of its application.

My recommendation/wish:

Producer: Display it clearly and ask for approval to transmit bug data to a central server. Show what you going to transmit. Make it optional.

Consumer: Let the software talk back. It will not help you this time, but with truckloads of bug reports flowing back the software, it will ultimately gets better and benefits everyone.

Sample (what Thunderbird sends back after crashing)

Application Launch Time
9/6/2008 2:33 PM
Build Identifier
2008070808
Deployment Identifier
MozillaOrgThunderbird2Win322008070808
Interface Version
8 (0x00000008)
Monitor Configuration Version
3 (0x00000003)
Platform Identifier
Win32
Product Identifier
Thunderbird2
Talkback Configuration Version
3 (0x00000003)

[..]

Event Description
32-bit Windows exception
Event Type
1 (0x00000001)
Information Collection Time
9/6/2008 2:47 PM
Memory Status
[   0] 20 00 00 00 2B 00 00 00 00 C0 5F 5F 00 B0 44 36 [ …+…..__..D6]
[  10] 00 80 2A D6 00 A0 0C B5 00 00 FE 7F 00 C0 6B 79 [..*………..ky]

[..]