Memory Profiling Using the JDE

RIM's JDE has some very useful (and sometimes unstable) tools for profiling Object usage in your application. Usually, you want to perform memory profiling when you're trying to find a memory leak or you're seeing excessive garbage collection during a specific function or process.

Getting Started with the JDE

1. Perform a root pom build on your app
2. Open up one of your RIM JDE's. They should be located at C:\tools\rim\jde-x.x.x. The file you want to run is \bin\ide.bat. Make sure that the JDE your using has access to the simulator you built your app to in step 1.
3. Set up your simulator options. Edit -> Preferences -> Simulator
4. To start the simulator, click the button in the toolbar that looks like "{}->"

Basic Object Profiling

1. Once your app is running, click the red stop sign button in the toolbar to stop execution. This is just like your app hitting a breakpoint in the debugger. Several windows will open the first time you stop the simulator.
2. If you don't see an Objects window, open one by clicking View -> Objects.
3. Click the GC button on the right side of the Objects window and wait for objects to load. This will force a garbage collection to ensure that you're not looking at objects that are soon to be collected.
4. From here you can do several things:
   1. Take a Snapshot. This is exactly what it sounds like. It saves the current list of objects. The Snapshot can then be compared to later Object lists to see which objects were added and removed. To compare to a Snapshot, click the box that says "Show All" and choose "Compare to Snapshot".
   2. Filter based on type. Just enter the Object type you want to see in the Type input box. You can use short or fully qualified names.
   3. Filter by process. This is very useful for seeing how many objects your app is using. Open a 'Processes' window (View -> Processes) and look for your app's name. Get the process id number and type it into the Process input box.
   4. Filter by Object location. There is a drop down box labeled 'Location' that lets you choose between persisted objects, objects in RAM, in Flash, and grouped objects. Usually, you'll want to just use the "All" selection, which is the default. Note that grouped objects do not show up in your app's process.
   5. Save Object list to a CSV... for hardcore profiling purposes.
5. You can sort the list by any of the columns. The most useful is object type and and object size.

Finding a Memory Leak

Once you have an Object list, there are two important things you can find out about each object:

1. Double clicking an object opens a list of its direct references
2. Right clicking an object gives the option of listing recursive references. This function is probably your best bet.

Find an object that you suspect could be leaked. This could be an object that really should not be in memory anymore. A quick way to find these objects is to close your app and then stop the simulator. Once you've got the suspicious object, open the list of recursive references. Look through the list to find references that just don't seem right. If you find one, right click it and select "Show path from xxx to aaa". This will open the list of references from the object, you suspect is leaking to the suspicious reference. This list will tell you why the object, you suspect is leaking, has not been garbage collected.

Watch Out for the Logger

When you're viewing objects in the JDE, you'll likely come across a significant number of objects created by the Logger. If you're not concerned with the Logger's memory usage and want to avoid seeing these objects, make sure to remove MEMORYLOGAPPENDER from your log4j configuration.