Java User Group Mannheim

Just a quick note: if you are in or around Mannheim, Germany, on November 25th, you might want to join Markus Kohler's presentation of the Memory Analyzer at the Java User Group Mannheim. The talks is at the University Mannheim at 7pm.

Troubleshooting Memory Problems from IBM Systems with Memory Analyzer

There was one question which popped-up at every Memory Analyzer demo we did in the last couple of years – “Is the Memory Analyzer able to read heap dumps also from IBM VMs”? And we always had to give negative answers. Not any longer!
After some joint efforts it is now possible to analyze memory problems which occurred on IBM VMs with the help of IBM’s DFTJ technology and the Memory Analyzer tool.

Overview

The Diagnostic Tool Framework for Java (DTFJ) is a Java API from IBM used to support the building of Java diagnostics tools. Using one and the same API – DTFJ - tools can read data from different data sources in a unified way. The IBM DTFJ adapter enables MAT to work with system dumps from IBM Virtual Machines for Java version 6, version 5.0 and version 1.4.2.

Setting-up the Tools

In order to analyze IBM system dumps with Memory Analyzer, one needs to install the DTFJ adapter into the Memory Analyzer. The DTFJ adapter as well as installation instructions are available here.

Getting Data for Analysis

A detailed documentation on using DTFJ with MAT is added to the “Help” of MAT once the DTJF adapter is installed. There it is described how dumps can be obtained and pre-processed. Further reading about DTFJ can be found in the “Diagnosis documentation”

Here I will only roughly present the process:

Get a system dump from the Java process

Run the jextract tool on the system where the dump was taken. This will produce a zip file which can be then analyzed on an arbitrary system

Open the jextract-ed file with the Memory Analyzer (which, of course, has the DTFJ adapter installed)

The minimum-required versions of the IBM JDKs are:

Java 1.4.2 SR12

Java 5 SR8a

Java 6 SR2

Analyzing the DTFJ Extracted Dumps

The analysis with the Memory Analyzer remains the same as for HPROF dumps. This means that if you have already some experience with the tool, you can just continue to do the analysis in the same way did before also for IBM dumps.

If you are new to the tool and need some “first steps” help, here are some resources which could help:

Look at the “Getting Started” part from the help coming with the tool

Look at our Blogs

Watch the recorded Eclipse webinar

If you want to see the Memory Analyzer & DTFJ in action, you can visit the “New & Noteworthy” short session at Eclipse Summit Europe 2008.

Automated Heap Dump Analysis: Finding Memory Leaks with One Click

There is a common understanding that a single snapshot of the Java heap is not enough for finding a memory leak. The usual approach is to search for a monotonous increase of the number of objects of some class by “online” profiling/monitoring or by comparing a series of snapshots made over time. However, such a “live” monitoring is not always possible, and is especially difficult to be performed in productive systems because of the performance costs of using a profiler, and because of the fact that some leaks show themselves only rarely, when certain conditions have appeared.

In this blog will try to show that analysis based on a single heap dump can also be an extremely powerful means of finding memory leaks. I will give some tips how to obtain data suitable for the analysis. I will then describe how to use the automated analysis features of the Memory Analyzer tool, which was contributed several months ago to Eclipse. Automating the analysis greatly reduces the complexity of finding memory problems, and enables even non-experts to handle memory-related issues. All you need to do is provide a good heap dump, and click once to trigger the analysis. The Memory Analyzer will create for you a report with the leak suspects. What this report contains, and how the reported leak suspects are found is described below.

Blog Post looks at Eclipse' Memory Consumption

Markus Kohler blogged about Analyzing Memory Consumption of Eclipse:

During my talk on May 7 at the Java User Group Karlsruhe about the Eclipse Memory Analyzer I used the latest build of Eclipse 3.4 to show live, that there's room for improvement regarding the memory consumption of Eclipse.

He goes on to have a closer look at the spell checker and looks at duplicate strings.

Now you may think, that this guy is bashing Eclipse, but that's really not the case.
If you beg enough, I might also take a closer look at Netbeans :]

If nothing else, it shows how relative simple it is to gain some insights about the memory of your application... :-)

Feedback on Memory Analyzer @ Java One 2008

Hello,

I just wanted to take the opportunity to thank everybody who joined our technical session at Java One 2008 - "Automated Heap Dump Analysis for Developers, Testers, and Support Employees".
I was very happy to see more than 400 people in the room, despite of the fact that the session was in the afternoon of the very last day of the conference. Thank you! It was a real pleasure for us the speakers.

As a project that is relatively new at Eclipse (was recently contributed by SAP) we are very interested to get some feedback from you - both about our JavaOne session and about the tool.

So I hope that we can get some comments added to this blog from the people who saw the session @ Java One and want to spend several minutes to give us their valuable opinion.

And for any feedback, suggestions or comments on the tool itself, please use our newsgroups.

For anybody who is interested in the topic and in the Memory Analyzer tool, but didn't have the chance to play with it yet - our project page is http://www.eclipse.org/mat/.