How to find that memory leak! (Part One)


Releasing an application with a memory leak can be one of the most embarrassing moments for a developer in the application’s lifecycle. Since mobile devices tend to have less free memory than a PC, the impact of a memory leak becomes more pronounced. Following the steps below will help ensure developers don’t encounter this situation when developing their application for BlackBerry® smartphones.

Leaks? What leaks?

Let’s start by clarifying how developers can end up with a memory leak in a Java® development environment. The Java Virtual Machine performs garbage collection on demand which frees up memory allocated by objects not referenced by anything else in the system – this puts Java applications in a better position than applications in a development environment like C++, for example. However, when an object that’s not needed anymore is left referenced by another object in your application, the JVM system has no way to know that this object should be freed up. This is especially true if instances of such an object get accumulated over time.

Our experience with BlackBerry development shows that in practice one of the most common cases for the creation of a memory leak is when registering listeners for system-wide events – for example, when registering your own email folder using ApplicationMessageFolderListener.  However, a memory leak can be created by just adding an object instance to the global runtime store and never removing it. Here is a very simple application that creates a new leak every time it is started:

import net.rim.device.api.system.Application;
import net.rim.device.api.system.RuntimeStore;
import java.util.Random;

class TestMemoryLeaks {
public static void main(String[] args) {
//create a memory leak by adding an item to the runtimestore and never removing it
RuntimeStore store = RuntimeStore.getRuntimeStore();
store.put((new Random()).nextLong(), new TestMemoryLeaks());

Of course, memory leaks can also exist within the scope of an application, but their impact is limited since they will be eliminated when the application terminates (unless the application is designed to always run in the background). In this category also fall all implementations of listeners registered for application-wide scope – for example AccelerometerListener. For such listeners, the underlying system uses WeakReferences; when the application terminates and no other objects have “strong” references to the listener, the system will automatically remove such WeakReferences and free up the objects.

In part two and three of this series, we’ll discuss how to detect a leak and identifying the root cause, respectively. Stay tuned!!

Join the conversation

Show comments Hide comments
+ -