BlackBerry Developer's Blog

[#1]

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!!

[#2]

Kamen,

This is an interesting and very important topic, but it seems that it is geared toward developers and not users.  I have a Verizon BB Storm 9530 running the latest official O.S. 5.0.  I have had a SEVRE memory leak issue for months now.  I've tried everything (getting a new storm, erasing everything and manually reloading, loading apps one by one to see which is the culprit) and I cannot find a solution.  It would be great if you could write an article or series of articles assisting us users with issues as well.  I can't seem to find what is causing the problem, but my Storm goes from operating perfectly with nearly 20 mb of memory to slow as dirt with less than 1 mb in one or two hours.

[#3]

That's a good suggestion for a future article, Ryan. Yes - the current post targets specifically developers.

Two lists of common-sense suggestions that may help an out-of-memory condition can be found here:

BBGeeks: 8 Ways to Trim the Fat From Your BlackBerry

eHow:How to fix or prevent Blackberry memory leak

Check if these would help in your particular case.

Kamen

[#4]

Yeah but come on!!!!! 20mb free, to less than 1 in an hour?  I see thousands a year and I've NEVER seen a memory leak that bad. Not even in the 8130. This is not a RIM issue.