BlackBerry Developer Blog » weakreferencehttp://devblog.blackberry.com
Tue, 03 Mar 2015 18:46:40 +0000enhourly1http://wordpress.com/http://1.gravatar.com/blavatar/9ef0a66c09615fa946c4179662398878?s=96&d=http%3A%2F%2Fs2.wp.com%2Fi%2Fbuttonw-com.png » weakreferencehttp://devblog.blackberry.com
How To Find That Memory Leak (Part Two): Detecting The Leakhttp://devblog.blackberry.com/2010/01/how-to-find-that-memory-leak-part-two-detecting-the-leak/
http://devblog.blackberry.com/2010/01/how-to-find-that-memory-leak-part-two-detecting-the-leak/#commentsFri, 29 Jan 2010 15:49:20 +0000http://blackberrydev.edstaging.com/?p=24/ Read More]]>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!

]]>http://devblog.blackberry.com/2010/01/how-to-find-that-memory-leak-part-two-detecting-the-leak/feed/1kamenv1How To Find That Memory Leak (Part Two): Detecting The LeakHow To Find That Memory Leak (Part Two): Detecting The LeakHow to find that memory leak! (Part One)http://devblog.blackberry.com/2009/10/how-to-find-that-memory-leak-part-one/
http://devblog.blackberry.com/2009/10/how-to-find-that-memory-leak-part-one/#commentsWed, 28 Oct 2009 17:39:03 +0000http://blackberrydev.edstaging.com/?p=236/ Read More]]>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:

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