In many instances, the code that you write is not as efficient as you would like to be. In this article, you will learn how to use profiling tools available in WSAD 5.0 to help you identify memory leaks, thread issues, and method response times in your code.

Initial Setup

The IBM Agent Controller must be installed for the Profiling Tool to function.

The WSAD 5.0 installation comes with an optional installation of the IBM Agent Controller. After the IBM Agent Controller is installed, the "serviceconfig.xml" properties file must be inspected to make sure that it is pointing to the correct installation directory of the WSAD. By modifying the properties file, you can modify the location of where the profiling results will be written. You also can modify the host name and port number of the agent as well as the logging level. The IBM Agent Controller can be stopped and started as a Windows service from the Control Panel –> Administrative Tools –> Services.

When you first launch the WSAD after the IBM Agent Controller is installed, you must set the profiling and logging preferences.

  1. From the WSAD main menu, select Window –> Preferences –> Profiling and Logging. You have to make sure that the "Enable Profiling" and "Enable Logging" checkboxes are checked. The Agent Controller local port number must match the port number specified in the "serviceconfig.xml" file of the controller (See Figure 1).

    Figure 1

  2. From the WSAD main menu, select Window –> Preferences –> Profiling and Logging –> Hosts. Here, you have to make sure that the default host for the agent controller is set up and is successfully connecting to the agent. The host should automatically get set.If it does not, add a new default host where host name and port number correspond to the parameters that are specified in "serviceconfig.xml". You can test the connection by clicking on the "Test Connection" button.

    Figure 2

Hands-on Example: Identifying Memory Leaks

In the first example, you will walk through a memory leak that you will identify using the profiling tool. Then, you will fix the leak, rerun the profiling session, and compare the difference.

First, let me define a memory leak. A memory leak is bug in a program that prevents it from freeing up memory that it no longer needs. As a result, the program grabs more and more memory until it finally crashes because there is no more memory left.

Now that you know the definition of a memory leak, try to find it in the following code. (The link to the full source code of this class, ProfileTestOne.java, is located in the zip file at the end of this article.)

1. public void leakingVector(int iter, int count) {

2.    for (int i = 0; i < iter; i++) {

3.       for (int n = 0; n < count; n++) {

4.          vector.add(new DummyClass(n + i));

5.       }

6.       for (int n = count - 1; n > 0; n–) {

7.          vector.removeElementAt(n);

8.       }

9.    }

10. }

Line 6 is where the leak occurs. The code does not remove the last element from the vector. With every call to the leakingVector () method, the vector will have more and more data in it and, after some period of time, it could crash the JVM.

Now, you can profile this method using the Profiler. The main method looks like this:

1. public static void main(String[] args) throws IOException {

2.    ProfileTestOne javaLeaks = new ProfileTestOne();

3.    for (int i = 0; i < 100 ; i++) {

4.       javaLeaks.leakingVector (100, 10);

5.    }

6. }