Web Age Solutions Inc
Providing Technology Training and Mentoring For Modern Technology Adoption
Web Age Aniversary Logo
US Inquiries / 1.877.517.6540
Canadian Inquiries / 1.877.812.8887


Web Age Solutions Inc.


HeapDiff is used to analyze memory leaks in J2EE applications running in WebSphere Application Server. It can compute differences between objects in heap, before and after memory leak had taken place. The program works with IBM heap dump files.

It is tested with IBM heap dump produced in WebSphere Application Server v5.0.x, 5.1.x and 6.x running in Linux and Windows.


Download latest version of HeapDiff. Just copy heapdiff.exe anywhere in a Windows XP or 2000 machine.


Configure the server in WebSphere v5.0.x and v5.1.x

Open Websphere admin console. Select Servers->Application Servers. Click on the application server name where the leaking application is running.

Click on Process Definition->Environment Entries.

Click on New.

Add a new variable called IBM_HEAPDUMP with the value true. Click on OK.

If you are using WebSphere 5.1.x, add another variable called IBM_JAVA_HEAPDUMP_TEXT with a value of trueImportant: This variable is needed, because IBM JDK 1.4 creates a binary heap dump by default. HeapDiff can currently handle text heap dump files only.

Save changes, restart the server.

Cause a Heap Dump in WebSphere 5.0.x, 5.1.x or 6.x

In UNIX, use the kill command:


Where, JVM_PROCESS_ID is the process ID (PID) of the Java process for the application server. You can find the PID in the server’s log folder, in a .pid file. For example, server1.pid. Another way to tell the PID is to open WebSphere admin console. Select Servers->Application Servers. Then click on the application server name. Click on the Runtime tab.

In Windows, launch the command line administration program wsadmin from the WebSphere\AppServer\bin folder.

First, enter the following command to obtain a reference to the application server.

set jvm [$AdminControl completeObjectName type=JVM,process=SERVER_NAME,*]

Where, SERVER_NAME is the display name of the server. For example, for server1, the command will be:

set jvm [$AdminControl completeObjectName type=JVM,process=server1,*]

Next, run the following command to generate the heap dump.

$AdminControl invoke $jvm dumpThreads

Exit out of the program by entering the quit command.

The heap dump file called heapdump.TIME_STAMP.txt will be created in the server’s working directory. By default, the working directory is WebSphere’s installation directory. For example, /opt/WebSphere/AppServer.

For more details, read this article.


The heap dump file can be very large – at least 30MB in size. You are not expected to manually go through the file and make any inferences from it. At the same time, it is good to know how the file is formatted. The file contains information about every Java object in the heap that existed at the time the heap dump was generated. IBM JDK 1.4 initiates a garbage collection prior to dumping the heap. In that scenario, all objects in the heap at the time of the dump should have a reference. For older JDK, there will be some objects in the dump file that are completely dereferenced and waiting to be collected.

The basic syntax of an object’s information in the file is as follows.


An example will make it easier to understand.

0x10180340 [304] class com/webage/beans/OrderBean
      0x101806D0 0x10180930
0x101806D0 [128] class com/webage/beans/AddressBean

The following observations can be made from the example above:

  1. There is an instance of the com.webage.beans.OrderBean class at the address location 0x10180340. The size of the object is 304 bytes.
  2. The OrderBean object has reference to two other Java objects. These two objects are at the address 0x101806D0 and 0x10180930.
  3. Elsewhere in the dump file, we should be able to locate these referenced objects. In this example, the address 0x101806D0 is occupied by an object of the com.webage.beans.AddressBean class. This object is 128 bytes in size.


Start the application server. Make sure that your J2EE application is running and functional. Take a heap dump.

Test the portion of the application that you think causes memory leak. If you are not sure, you can do a general stress test that is known to produce memory leaks. Take another heap dump.

The two heap dump files will have similar names. To avoid confusion, you may want to rename them to clearly indicate whether a file is produced before or after the stress test.

Copy the two heap dump files to the Windows machine where HeapDiff is installed.

Launch HeapDiff.exe. From the menubar, select File->Open Dump Files.

Use the Browse buttons to locate the before and after dump files. Then click on OK.

System will show the data in these columns:

  • Count Before – Number of objects of a class before leakage
  • Count After – The same after leakage
  • Size Before – Total size in bytes of all objects for a given class
  • Size After – The same after leakage.
  • Count Difference – Number of new instances created and still live in memory
  • Size Difference – The difference in size before and after leakage.
  • Class Name


You can sort a column by clicking on the column header. Usually, sorting by the count difference or the size difference column can show you the classes that have leaked most.

You can also sort by the raw count or size columns to determine which classes are taking up most memory.


You can export the heap difference data as a comma separated (CSV) file for further analysis. Select File->Export CSV File from the menubar. The exported file can be loaded into MS Excel or any other spreadsheet program.


HeapDiff is protected by copyright. You are free to use it. Please let us know if you find the tool to be useful.


US Inquiries / 1.877.517.6540
Canadian Inquiries / 1.877.812.8887