Tracking Memory Leaks

From Event-B

It can happen that a plug-in consumes a lot of memory, and, worse, never releases it. This recently happened to the new Predicate Prover plug-in. While looking for a proof, it was allocating megabytes of memory, and upon cancellation the memory was not garbage collected. This impeded seriously proving, as attempting to use this prover was allocating memory that was never freed. Users then had to manually restart the platform every third or fourth attempt of using this prover.

This document explains how such memory leaks can be examined and how one can trace their origin using simple useful tools. The proposed method consists in using the JVM heap dump feature, together with an external tool for inquiring into a heap dump.

Producing a Heap Dump

This document supposes that the standard JVM from Sun (or the one bundled with Mac OS X) is used.

To produce a heap dump, add the following VM argument to the command used to launch the platform (e.g., in the tab of the dialog of Eclipse):

  -Xrunhprof:format=b,file=/tmp/xx.hprof

When given this argument, he JVM will write in the specified file (here ) a copy of the heap upon program termination. It is also possible to force a heap dump while the application is running by sending a QUIT signal (number 3) to the JVM while it is running (I don't know how to do that on Windows platforms).

Analysing a Heap Dump

With the Java 6 JDK, there is a bundled tool called that allows to analyse a heap dump. However, SAP developed another tool based on

Eclipse which is more user-friendly and easy to use. This tool is available from (free registration required):

https://www.sdn.sap.com/irj/sdn/wiki?path=/display/Java/Java+Memory+Analysis

The online help of the tool is very well done and gives various strategies for analysing the allocated memory at the time of the dump.