Using JProfiler To Resolve Memory Leaks

This document describes how to use JProfiler to verify a memory leak in a Nexaweb application and to identify its probable source.

Memory leaks occur by objects and object collections that get created by an application that are no longer used but that Java cannot destroy because they are referenced by other objects in the application. This proliferation of unused objects creates an increasing hold on memory causing the application to run less and less efficiently as it runs out of memory.

You can use JProfiler to look inside of an application while it's running. This enables you to see what's happening with all of the objects the application creates and how they relate to each other, and to track down the objects or object collections that are the probable source of memory leaks. 

Downloading JProfiler

Click here to download an evaluation copy of JProfiler.

Setting up JProfiler

After launching JProfiler, the JProfiler Quick Start dialog appears.

1. Click An application on a remote computer radio button and click Next.
    Note: This choice allows you to run any type of application from a Browser, Nexaweb Studio or a
              command line.
    The Where is profiled application located? dialog appears.

2. Click On this computer radio button and click Next.
    The Choose JVM Version . . . dialog appears.

3. Select the JVM version running on your system and click Next.
    The Choose the port used for profiling connection dialog appears.

4. Click Next to accept the default.
    The Choose whether to wait for the JProfiler GUI dialog appears.

5. Click Next to accept the default.
    The Perform required modifications dialog appears.

6. Modify the Java start command to include the syntax specified in the
    Perform required modifications dialog.

    To profile an application from Nexaweb Studio, modify the Java start command syntax within 
    Nexaweb Studio. Otherwise, modify it from the Java Control Panel.
    See: To Modify the Java start command in Nexaweb Studio or
            To Modify the Java start command from the Java Control Panel.

    Click Next.
    The Finished dialog appears.

7. Select whether to start a session now or later and click Finish. 

To modify the Java start command in Nexaweb Studio:

a. In Nexaweb Studio select Windows > Preferences.
    The Preferences dialog appears.

b. Click + to expand Java and select Installed JREs.

c. Select Nexaweb Studio from Installed JREs list and click Edit.
    The Edit JRE dialog appears.

d. Enter the JProfiler command syntax (specified on the Perform required modifications dialog) in the
    Default VM Arguments field.

e. Click OK until the Preferences dialog closes.

To modify the Java start command from the Java Control Panel:

a. Select Program Files > Settings > Control Panel.
    The Control Panel folder opens.

b. Double click on Java.
    The Java Control Panel opens.

c. Click Java Tab.

d. Click View for Java Applet Runtime Settings.
    A list of Java runtime settings for the JREs installed on your system appears.

e. Click in the JavaRuntime Parameters field beside the JRE to use and enter the information specified on
    the JProfiler Perform required modifications dialog in this field. For example, enter: 
    -agentlib:jprofilerti=port=8849  "-Xbootclasspath/a:C:\Program Files\jprofiler5\bin\agent.jar"

f. Click OK to close the Java Runtime Settings dialog.

g. Click Apply and OK to close the Java Control Panel.

Verifying Memory Leaks

JProfiler allows you to view a graph of memory usage while an application runs. You can verify whether an application leaks memory by determing whether the overall amount of memory the program uses increases over time rather than returning to a constant level between activity spikes and dips.

To use JProfile to verify a memory leak, follow these steps:

1. If you selected to start a session after configuring JProfiler, the Session Startup dialog appears.
    Otherwise, select Session > Open Session.  An Open Session dialog appears.
    Select Remote application on local host and click Open. The Session Startup dialog appears.
    Note: If using an evaluation copy of JProfiler, an evaluation dialog appears.
              Click Evaluate to get to the Session Startup dialog.

2. Click OK.
    A Connection status dialog appears.

3. Start the application that you want to profile.

4. Click VM Telemetry Views on the left of JProfiler. Then click the Memory tab at the bottom, if not
    already selected.

5. Use the application and watch the application performance in JProfiler. 

The following graph shows an application with a memory leak.

Identifying Memory Leak Source

1. Click  to cause the JVM to start collecting objects.

2. Click Memory Views.

3. Filter the view to display Nexaweb objects only; enter: com.nexaweb in the filters field and 
    press the Return key.

4. Select View > Mark Current Values.
    This causes JProfiler to remember all classes and number of instances of each in the application. 
    In addition, it adds a Difference column to the Memory view.

5. Click  to cause the JVM to start collecting objects.

6. Use the application and observe the values changing in the Difference column.
    You can rule out objects for which JProfiler records a 0 in the Difference column
    as being the source of the memory leak.

7. Select an object with values in the Difference column and then click .
    JProfile displays a dialog prompting you to discard the current snaphsot, if one has already been taken,
    click OK.
    JProfiler displays a dialog prompting you to select options for the snapshot.

8. Click Remove weakly referenced objects check box and click OK.

9. Double-click the object.
    A New Object Set dialog appears.

10. Click References radio button and click OK.
      JProfiler displays a Reference graph.

11. Right click on an object and select Show Paths to GC Root.
      A Path to GC Roots options dialog appears.

12. Click Single root radio button and then click OK.
      This locates and displays the link from a GC root object, a permanent object in memory that
      is not released, to this object.    

The GC root appears in yellow.

13. Follow path from selected object to GC root and look for collections, which appear with [] in the title 
     similar to the following:

Collections typically are arrays or hash tables. These are most likely objects causing memory leaks, as the application puts objects in collections and then forgets about the collections. However, since the collection is referenced it cannot be destroyed.

After identifying a referenced object collection, to resolve the memory leak, locate this object in the source code and analyze what is happening with it.