BlackBerry Developer Blog » Kamen V.

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.

How To Find That Memory Leak (Part Two): Detecting The Leak

Kamen V. — Fri, 29 Jan 2010 15:49:20 +0000

In part one of our memory leak how to series, I explained the most common cases for a memory leak in a Java® development environment, and how that can affect your application. Today we’ll discuss how to detect potential leaks.

Application memory leaks are usually not that easy to find – the application may need to be left running for a while, may need to be started multiple times, or specific application logic may need to get exercised repeatedly. If you suspect a memory leak then the first step is to start monitoring the device’s free memory – Options/Status/File Free. A more reliable way to monitor device memory usage is through the memory tools that can be found in the BlackBerry® Java® Development Environment (BlackBerry JDE) when connected to either the simulator or a real device. To use them you need to break the execution through a breakpoint or through the menu – Debug/Break. Once the execution has been suspended go in the View menu where you will find two tools of particular interest – Memory Statistics and Object Statistics.

The Memory Statistics show a detail breakdown of the memory that’s being used:

Columns

objects – displays the number of objects that are currently in memory
Bytes in use – displays the amount of memory that is used by Java® objects
Allocated – displays the total memory that is allocated to the VM
Free – displays the memory that is available

Rows

Transient objects – displays the number of transient objects in flash memory
Persistent objects – displays the number of persistent objects in flash memory
Code modules – displays the number of code modules in flash memory
Flash – displays the sum of the other three rows

Pressing Refresh will populate the table with data. Press Snapshot to save the data in a snapshot. Next resume the execution and perform the steps that you suspect of causing memory leaks .The more memory leaks you manage to accumulate the easier it would be spot them so be bold here. Now break the execution again, press Refresh on the Memory Statistics window, and select “Compare to Snapshot” . This should show you the difference between the current memory statistics and the snapshot you previously created.

Another tool that you can use is the Object Statistics tool under the View menu. First press the “GC” button to make sure all object instances that are not referenced are freed up. Then sort the table by “Number of instances” and use the “Type:” field to filter them by your application’s package name. Look for classes that have more instances that you expect them to have:

Now you should be ready to proceed with investigating why an object is leaking into memory. We’ll deal with this issue in part three of our series, so stay tuned!

How to find that memory leak! (Part One)

Kamen V. — Wed, 28 Oct 2009 17:39:03 +0000

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

How-to Set up a Lightning Fast BlackBerry Smartphone Simulator

Kamen V. — Sat, 29 Aug 2009 12:54:22 +0000

Many times while coding an application for BlackBerry® smartphones, I want to quickly start the BlackBerry® Smartphone Simulator and see what I have achieved so far. Micro-iterative coding is my style of choice. I don’t need to debug any code, I just want to see it running; If it doesn’t work, then I’ll begin debugging. For those of you who share the same coding approach, here is a tip on how to make your BlackBerry Smartphone Simulator launch lightning fast.

BlackBerry Smartphone Simulator Initial Launch

The BlackBerry Smartphone Simulator keeps all simulated flash memory in .DMP files – you can find these in the simulator’s working directory. Whenever you need to get rid of any persistent data that you have accumulated, you can either delete these files manually or do it from within the BlackBerry® Java® Development Environment (BlackBerry JDE) or the BlackBerry® JDE Plug-in for Eclipse. This acts as a grand reset giving you the equivalent of a brand new BlackBerry® smartphone. However, the next time the BlackBerry Smartphone Simulator launches it will need to load all the OS files (including any applications it finds in the current directory) and link them within the newly created file system. This obviously takes time – possibly up to 3 minutes. On the IBM® ThinkPad W500 I use at work it takes 32 seconds which is still a considerable wait time.

So, rule number one: delete the BlackBerry Smartphone Simulator file system only when necessary.

There is also an option to automatically reset the file system every time you start the BlackBerry Smartphone Simulator – make sure it is also turned off unless you really need it.

In the BlackBerry JDE, you can find it by selecting Edit -> Preferences -> Simulator -> Memory and unchecking the “reset file system on startup” option.
In the BlackBerry JDE Plug-in for Eclipse, select Debug -> Run Configuration and uncheck the option under the Memory tab.

Debug Sessions

The debug session is a connection established between the BlackBerry JDE and the BlackBerry Smartphone Simulator to enable… well, debugging. Establishing a debugging session requires many prerequisites to be prepared both on the BlackBerry Smartphone Simulator side and on the debugging tool side. When the debugging session is established on my laptop it takes 32 seconds for initial launch and 16 seconds for subsequent runs. Without debugging it takes 23 seconds for initial launch and 10 seconds for subsequent launches!

Rule number two: establish a debug session only when you have a specific problem to debug.

Don’t worry – if you run the application and find a problem, you can still attach the debugger:

In the BlackBerry JDE, select Debug -> Attach To -> Simulator or press Ctrl-Shift-0.
In the BlackBerry JDE Plug-in for Eclipse, choose “Running BlackBerry Simulator” as your Debug Configuration.

How to run the BlackBerry Smartphone Simulator without Debugging

Now that it is apparent how much time we can save, let’s see what we need to do in order to avoid establishing a debug session. With the BlackBerry JDE Plug-in for Eclipse it’s pretty straightforward – simply select “Run” instead of “Debug” or use the CTRL-F11 shortcut and the BlackBerry Smartphone Simulator will launch right away. Using the BlackBerry JDE requires the slightly more involved process of creating a batch file:

Open the BlackBerry Smartphone Simulator Properties menu and select Edit -> Preferences -> Simulator and then select the Advanced tab.
Here you have the actual command line that can launch the BlackBerry Smartphone Simulator with all the necessary command line options; every time you change an option under the Simulator tab it is reflected in this command line. You also have the proper working directory where the BlackBerry Smartphone Simulator should start in order to pick up any compiled applications.

Now you can create your runBBSim.bat:

pushd "[workingDirectory]"

"[cmdLine]"

popd

Now replace [workingDirectory] and [cmdLine] with the contents of the corresponding fields on the Advanced subtab of the BlackBerry Smartphone Simulator preferences: Command Line and Working Directory. Don’t forget to put quotes around any paths containing spaces to make the Windows command-prompt happy.

Here is what my batch file looks like:

pushd "C:\Program Files\Research In Motion\BlackBerry JDE 4.7.0\bin\..\simulator"

"C:\Program Files\Research In Motion\BlackBerry JDE 4.7.0\bin\..\simulator\fledge.exe" /app=Jvm.dll /session=9500 /app-param=DisableRegistration /app-param=JvmAlxConfigFile:9500.xml /data-port=0x4d44 /data-port=0x4d4e /pin=0x2100000A /handheld=9500

popd

Now you can compile the application in the BlackBerry JDE, start the batch file, and in 10 seconds you will have a running BlackBerry Smartphone Simulator with your application installed on it! Sounds like too much trouble? Believe me it’s worth the effort!

Do you have any other tricks for speeding up the BlackBerry Smartphone Simulator? Let us know by posting a comment.