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