How To Find That Memory Leak (Part Three): Why An Object is Leaking Into Memory

Kamen V. — Tue, 09 Mar 2010 10:00:00 +0000

This is the third of a three-part series on how to detect a memory leak. In part one, I explained the most common cases for a memory leak in a Java® development environment, and how that can affect your application. In part two, I discussed how to detect potential leaks. Today, we’re going to investigate why an object is leaking into memory in the first place.

Leak investigation

Once you’ve identified the class name of the object that is leaking, open the object’s view – View/Objects. This view allows viewing all class instances currently on the BlackBerry® smartphone. Before proceeding, press the “GC” button to clean any unreferenced instances (you may have done this already in the Object Statistics view, but doing it again doesn’t hurt). Starting with the BlackBerry® Java® Development Environment (BlackBerry JDE) v4.6, you can take advantage of a convenient functionality that lets you show all recursive references to an instance. So if you’re using BlackBerry JDE 4.6 or newer, follow the set of instructions below; otherwise look at the second set of instructions.

In the “Type:” field, enter the name of the class you’re after – e.g. “TestMemoryLeaks” – and press enter. You will get a list of instances – these are the actual “leaks”.
Pick one of those instances in the objects view, right-click and choose “Show Recursive References”. This will yield a very large list of objects (everything that references your object, directly or indirectly).
In the “Location” dropdown, select “Root Objects”. This will restrict the view to root references only (static variable, persistent root, app registry, local variables, etc).
One of the instances in the list will be of a class called ApplicationRegistryHashtable. Right click on it and choose “Show paths from @xxxxxx to @yyyyy”.
Now you have the reference chain that causes the leak.

If you have a version of the BlackBerry JDE older than 4.6, use the following steps:

In the “Type:” field, enter the name of the class you’re after – e.g. “TestMemoryLeaks” – and press enter. You will get a list of instances – these are the actual “leaks”.
Pick one of those instances in the objects view, right-click and choose “Show References to @xxxxxxx”. This will give you a list of immediate references.
Check if one of the instances in the list is not ApplicationRegistryHashtable. If it is then go to step 6.
Right-click on any item in the new list and select “Show References To This Object List”. This will give you another list.
Repeat steps 3 and 4 until you reach an instance of ApplicationRegistryHashtable.
Right-click on ApplicationRegistryHashtable and choose “Show paths from @xxxxxx to @yyyyy”.
Now you have the reference chain that causes the leak.

Having the reference chain to the leaked object instance should provide you with enough information about what caused the problem, and to avoid it.

So enough reading, hunters – minimize this browser and go back to your BlackBerry JDE to start the memory leak hunt! After that, come back and share your experience with everyone by posting a comment. Have you found any leaks? What were the core reasons for having the leaks on the first place? Let us all know.

BlackBerry API Hidden Gems (Part One)

Denver C. — Wed, 12 Aug 2009 12:27:00 +0000

Every time I think I know everything, I am always proven wrong. For example, I used to think I knew everything about BlackBerry® APIs but as I continue developing software I am still finding new, cool classes and methods that make my life easier. I call them “hidden gems” since they are often found by one stumbling across them, but when found are of great use. In this post I will highlight some of my favourite gems, which I hope will make your life as a developer easier too. So let’s dive in.

Weak References

For the longest time I had heard the term “weak references” but never really knew what they were. Once I finally learned, I started to use them all the time to be more efficient and avoid memory leaks. Indeed, weak references are not BlackBerry specific, but are defined right in the CLDC specification in the class java.lang.ref.WeakReference.

So what is a “weak reference” anyways? The behaviour of a weak reference when contrasted with the normal “strong” reference pertains to making an object a candidate for garbage collection. A weak reference gives you the ability to access an object but also makes it available to the garbage collector. So why would this be useful? I find that there are often circumstances when you only care about an object if someone else does. Holding a weak reference to an object is one way of determining if anyone else cares about it, based on the assumption that anyone who cares about it will hold a strong reference to it. Once nobody cares about the object (other than me) it will be garbage collected. This is the opposite of holding a strong reference to the object, as doing so would prevent the object from being garbage collected, wasting precious memory.

One excellent use case for weak references is holding a reference to an application object. In general, you only need to reference an application object while the application it represents is alive; once the application exits you no longer need the reference. By holding a strong reference to the application object, the garbage collector will be prevented from freeing the object’s memory even after the application exits, along with the massive number of objects that it recursively references. Instead, holding a weak reference to the application object allows it to be garbage collected when the application exits.

Below is an example of how a weak reference to an application object can be used in a memory-efficient manner to determine if an application is still alive.

import net.rim.device.api.system.Application;

import java.lang.ref.WeakReference;

public class ApplicationLifeMonitor {

private WeakReference _appRef;

public ApplicationLifeMonitor() {
Application app = Application.getApplication();
_appRef = new WeakReference(app);
}

public boolean isAlive() {
Application app = (Application) _appRef.get();
return (app != null && app.isAlive());
}
}

UIDGenerator

The UIDGenerator class does exactly what its name implies: generates unique IDs. Its class javadocs defines it as “a utility class to generate 32-bit unique IDs that can be used for synchronization or any other purpose.” Here’s an example to show how it could be used:

public class Person {

private int _id;
private String _name;

public Person(String name) {
this._id = UIDGenerator.getUID();
this._name = name;
}

public int getId() {
return this._id;
}

public String getName() {
return this._name;
}
}

IOUtilities.streamToBytes()

Have you ever written code like this to dump the bytes from an InputStream into a byte[] array?

public static byte[] getBytes(InputStream in)

throws IOException {

ByteArrayOutputStream out = new ByteArrayOutputStream();

byte[] buffer = new byte[2048];

int readCount = in.read(buffer);

while (readCount >= 0) {

out.write(buffer, 0, readCount);

readCount = in.read(buffer);

}

return out.toByteArray();

}

Now you can do it in one line:

public static byte[] getBytes(InputStream in)

throws IOException {

return net.rim.device.api.io.IOUtilities.streamToBytes(in);

}

Impress your friends at your next party with this neat trick.