Embarcadero J Optimizer Tutorial...1. Remote Attach using the J Optimizer Agents. You can run the application on a remote machine or local machine. On the remote machine, you run the

Corporate Headquarters EMEA Headquarters Asia-Pacific Headquarters 100 California Street, 12th Floor San Francisco, California 94111

York House 18 York Road Maidenhead, Berkshire SL6 1SF, United Kingdom

L7. 313 La Trobe Street Melbourne VIC 3000 Australia

Tutorial

Embarcadero® J Optimizer™ Tutorial

May 2009

Embarcadero J Optimizer Tutorial

Embarcadero Technologies - 1 -

TABLE OF CONTENTS

Introduction ...................................................................................................................................... - 3 -

Overview of J Optimizer ............................................................................................................. - 3 -

Set up the Tutorial Sample Application ..................................................................................... - 4 -

Import AddressBookWeb source code into J Optimizer ...................................................... - 4 -

Deploy the WAR file to Tomcat 6 Using Tomcat Manager. .................................................. - 5 -

Configuring and Starting the Tomcat Server with J Optimizer ............................................ - 7 -

Attaching to J Optimizer Agent, adding Source Code, and Starting the Profiler ............ - 12 -

Overview of this Tutorial ............................................................................................................... - 17 -

The Address Book Test Application ........................................................................................ - 17 -

Scenario 1: Excessive Temporary Object Allocations ................................................................. - 18 -

Excessive char Array Allocations .............................................................................................. - 18 -

Step 1: Run the application with the Profiler. ....................................................................... - 18 -

Step 2: Configure the Profiler for tracking temporary object allocations and run a transaction .............................................................................................................................. - 21 -

Step 3: Find out where in the code the char arrays are created ......................................... - 23 -

Excessive Integer Object Allocation ........................................................................................ - 25 -

Step 1: Search for other excessive temporary allocations ................................................. - 25 -

Step 2: Discover which parts of the code create the Integer objects ................................ - 26 -

Step 3: Check that we fixed the excessive allocation of temporary Integer objects ........ - 28 -

Step 4: Use Progress Tracker to verify that we fixed the excessive object allocation....... - 29 -

The Application is Now Far More Scalable ............................................................................. - 30 -

Scenario 2: Solving Memory Leaks ............................................................................................... - 31 -

What are memory leaks in Java? .............................................................................................. - 31 -

Symptoms of Memory Leaks..................................................................................................... - 31 -



Investigating Memory Leaks with the Memory and Instance Views ...................................... - 31 -

Step 1: Look for leaked objects in a session ........................................................................ - 32 -

Step 2: Investigate the potential leaked Strings .................................................................. - 34 -

Step 3: Run the fixed version ................................................................................................. - 36 -

Investigating the Memory Leak with the Automatic Memory Leak Detector ....................... - 37 -

Step 1: Find the memory leak ............................................................................................... - 37 -

Step 2: Use Progress Tracker to verify that we fixed the memory leak .............................. - 40 -

Scenario 3: Identifying Bottlenecks .............................................................................................. - 41 -

Step 1: Determine where time is spent when we perform a request on the Address Book - 41 -

Step 2: Use a flat cache ............................................................................................................. - 44 -

Step 3: Use Hash tables for caching ......................................................................................... - 46 -

Step 4: Use Progress Tracker to verify that we reduced the CPU usage ............................... - 47 -

Scenario 4: Improving Code Quality with Code Coverage ........................................................ - 49 -

Run a unit test with Code Coverage ........................................................................................ - 49 -

Scenario 5: Thread Debugging .................................................................................................... - 51 -

Step 1: Run the thread debugging example ........................................................................... - 51 -

Step 2: Analyzing and predicting thread locks ........................................................................ - 54 -

Step 3: Eliminating “Random” thread Locks ........................................................................... - 55 -

Conclusion: Key Differentiators of J Optimizer ........................................................................... - 57 -

Productivity Benefits .................................................................................................................. - 57 -

Ease of Use ................................................................................................................................. - 58 -

Tight integration with Eclipse based IDEs ............................................................................... - 58 -

Truly scalable ............................................................................................................................. - 58 -

Low Overhead ............................................................................................................................ - 58 -



INTRODUCTION The iterative use of performance tools throughout the development process is critical for keeping performance and reliability problems under control as well as for producing fast, scalable J2EE and J2SE applications. Java technology is great for accelerating time-to-market; but, performance and reliability risks can become a serious challenge. Because Java technology provides a higher level of abstraction, it affords developers only a limited understanding of—and control over—the way their code is executed.

J Optimizer provides a complete set of tools for measuring and optimizing the performance of Java programs, including the Memory and CPU Profiler, Code Coverage tools, the Thread Debugger, the Request Analyzer, and the Snapshot Analyzer. Because J Optimizer is IDE-independent it can be used on virtually all J2SE and Java EE programs.

Note: This tutorial covers Profiler, Code Coverage and Thread Debugger. A separate tutorial covers the Request Analyzer.

OVERVIEW OF J OPTIMIZER J Optimizer equips Java and JEE developers with a comprehensive toolkit for optimizing performance and managing application quality throughout the development lifecycle. The J Optimizer perspective extends from higher-level J2EE diagnostic metrics down to code-level granularity.

You can use J Optimizer to track performance bottlenecks at the JDBC, JMS, JNDI, JSP, EJB, CCI, and Web Services levels, and locate the exact line of source code for root-cause analysis. You can also profile memory and CPU usage, display real-time threading information, and determine which parts of your code are executed. You can use J Optimizer with the following types of Java programs:

• Applications • Applets • Servlets • JavaServer Pages (JSPs) • JavaBeans • Enterprise JavaBeans (EJBs) J Optimizer consists of a Profiling Agent and four profiling tools: Profiler, Code Coverage, Thread Debugger, and Request Analyzer. The profiling agent collects data from the application you want to test using the profiling tool you specify. Each tool has its own data-collecting Agent. For example, the Request Analyzer Agent collects data about JEE protocols, while the Code Coverage Agent collects data on code use. You can launch only one profiling tool at a time.



There are two ways to use J Optimizer:

1. Remote Attach using the J Optimizer Agents. You can run the application on a remote machine or local machine. On the remote machine, you run the standalone Agent Controller on the host where the application resides.

2. J Optimizer has touch-point integration with Eclipse based IDEs. In this case, you can develop, debug, and optimize your code in your Eclipse based environment, so you never have to leave your IDE.

This tutorial covers using J Optimizer as a stand-alone application.

SET UP THE TUTORIAL SAMPLE APPLICATION This document presents a tutorial script that reveals some real-life performance problems that you can encounter in Java applications and how to use J Optimizer to indentify and fix those problems. The script operates on a web application that has been developed in JBuilder® 2008. It can be created with any IDE that can produce a WAR file.

A zip file AddressBookWeb_JOptimizer.zip that is included with the tutorial package provides the Eclipse workspace project necessary for following this tutorial script.

Prerequisites for Following This Tutorial Script This tutorial script uses J Optimizer and apache-tomcat-6.0.14 (Note: apache-tomcat-6-0.14 is included on the JBuilder 2008 DVD).

IMPORT ADDRESSBOOKWEB SOURCE CODE INTO J OPTIMIZER 1. Create a new workspace in J Optimizer by selecting File | Switch Workspace | Other and

type the location of your new workspace. For example, C:\JOptimizer\MyWorkspace. 2. Switch to the Java perspective Window | Open Perspective | Other | Java. 3. Import AddressBookWeb_JOptimizer.zip into your new workspace by selecting File |

Import | General | Existing Projects into Workspace. 4. Click Next. 5. Select archive file and browse to AddressBookWeb_JOptimizer.zip.

Figure 1 Select the tutorial projects.

6. Verify that the AddressBook, AddressBookWeb and Server2 projects are selected. 7. Click Finish.



DEPLOY THE WAR FILE TO TOMCAT 6 USING TOMCAT MANAGER. 1. Start Tomcat 6 using the startup.bat from C:\JBuilder2008\thirdparty\apache-

tomcat-6.0.14\bin. 2. From Tomcat home page: http://localhost:8080, select Tomcat Manager

3. Enter Username and Password.

Note: If this is the first time you are using Tomcat Manager, you will need to modify conf/tomcat-users.xml in your Tomcat installation. That file will contain the credentials to let you use this Tomcat Manager webapp.

4. You will need to add the manager role to the configuration file listed above, like this:

<?xml version='1.0' encoding='utf-8'?>

<tomcat-users>

<role rolename="manager"/>

<user username="tomcat" password="s3cret" roles="manager"/>

</tomcat-users>

5. Re-start Tomcat for this change to take effect.

6. After you log into Tomcat Manager, from the Tomcat Web Application Manager, scroll down to WAR file to deploy, and Browse to the AddressBookWeb.war file from the example for this tutorial. The extract should have placed the file at: C:\AddressBook\AddressBookWeb.war

7. Click Deploy.



8. Scroll up, and you should see the AddressBookWeb deployed to Tomcat, as shown in Figure 2.

Figure 2 Verify that /AddressBookWeb is deployed on Tomcat.

9. To test the AddressBookWeb got deployed, from a browser, enter:

http://localhost:8080/AddressBookWeb/enter1

You should see this. Congratulations!

10. Run shutdown.bat from C:\JBuilder2008\thirdparty\apache-tomcat-6.0.14\bin to shutdown Tomcat.




CONFIGURING AND STARTING THE TOMCAT SERVER WITH J OPTIMIZER To create an application server profile configuration in J Optimizer:

1. Open Window | Preferences. 2. Navigate to J Optimizer | Agent Configuration. 3. In the right pane of the Agent Configuration window, click Add to add a new agent

configuration. 4. On the Add J Optimizer Agent Configuration window, select the Tomcat 6.0 server.

Figure 3 Select your Tomcat server.

5. Then click Next. 6. Browse to and select the application server's home directory,

Figure 4 Browse to the Tomcat home directory.

7. Then click Next.



8. On the J Optimizer Configuration page, select the Profiler as the tool you want to use, shown in Figure 5.

Figure 5 Select Profiler as the tool you want to use.

9. On the same screen, click Details to configure the tool's settings. 10. Select Memory. 11. Check Disable Garbage Collection.

Figure 6 Ensure garbage collection is disabled.

Note: When Disable Garbage Collection is selected, J Optimizer reports object counts as if the garbage collector were disabled, enabling us to discover precisely how many objects are created, including those that have been garbage-collected.

The preferred way to investigate excessive temporary allocation problems is to set "Report Live and Freed" in the "Report Freed/Live Object" combo-box. This will allow you to view garbage-collected objects.



For this tutorial we are using Disable Garbage Collector to show just how many objects can get created from a one simple transaction.

12. Click OK. 13. Click Next. 14. Review the Integration Summary page and click Integrate. The following actions will be performed for the integration:

• Generate the script file startup-with-optimizeit.bat to start Tomcat with J Optimizer. • Generate the script file opti_tomcatsvc_init.bat to optionally start Tomcat with J Optimizer

as a service. • Generate the J Optimizer configuration file optimizeit.xml. These files get created in C:\JBuilder2008\thirdparty\apache-tomcat-6.0.14\bin

Note: The created startup-with-optimizeit.bat uses the –Xrunoii parameter. This –Xrunoii looks at the setting of your oiselector.exe and starts Tomcat with that tool (Profiler, Thread Debugger, Code Coverage or Request Analyzer).

15. Execute oiselector.exe (located in C:\JOptimizer\joptimizer-agent\bin).

This adds the J Optimizer selector in your tool tray as shown in Figure 7. If Profiler is not selected, then right-click the icon and select Profiler.

Figure 7 J Optimizer in your tool tray.

16. Start Tomcat with J Optimizer attached. To start the Tomcat 6 Application Server:

- In the right pane of the Agent Configuration window, Select Tomcat 6.0, and click Start.



Look at the Console to watch application server output. The Tomcat application server should now be running with the J Optimizer agent.

Note: If Console output says: Cannot find C:\JOptimizer\bin\java.exe this most likely means your JAVA_HOME is not set correctly. You can fix this by adding: set JAVA_HOME = C:\JBuilder2008\jre to the startup-with-optimizeit.bat like this:

set JAVA_HOME=C:\JBuilder2008\jre

set OPTIT_HOME=C:\JOptimizer\joptimizer-agent

set PATH=%OPTIT_HOME%\bin;%PATH%

set EXECUTABLE=%JAVA_HOME%\bin\java.exe

17. With a successful start, the Console output (Window | Show View | Console) should include: Reading configuration from file ..\bin\optimizeit.xml

**************************************************

J Optimizer Profiler enabled

Port 1470

JVMPI enabled

Note: You can also run startup-with-optimizeit.bat from a command line and get the same results. You can start and stop Tomcat either from within J Optimizer or by running startup-with-optimizeit.bat to start and running shutdown.bat to stop.



A successful startup within J Optimizer will display the dialog box shown in Figure 8.

Figure 8 Profiling message from successful startup.

18. Click OK.

Note: You are using a socket connection, so verify that the correct port number appears for the profiling tool you selected. The following table specifies the port range available for each tool. These values are defined in the optimizeit.xml file created from the Integration above.

Port Number Profiling Tool

1470 to 1480 Profiler (Memory and CPU)

1471 to 1481 Thread Debugger

1472 to 1482 Code Coverage

1473 to 1483 Request Analyzer

The console output should say:

J Optimizer Profiler enabled

Port 1470

You are now ready to attach to J Optimizer and start profiling!



ATTACHING TO J OPTIMIZER AGENT, ADDING SOURCE CODE, AND STARTING THE PROFILER Note: If you are attaching to J Optimizer using a socket connection, use the following steps. If you were using a TPTP connection, then follow the next section on TPTP connection.

To attach the Tomcat application server (using a socket connection) to J Optimizer and start profiling:

1. Open the Profile Configuration wizard.

Figure 9 Open the Profile Configuration wizard.

2. In the left pane, right-click on Attach – J Optimizer Agent and select New from the context menu. The Profile Configuration wizard opens in the right pane.

3. Enter “Tomcat 6” for Name (or you can name it anything you want), shown in Figure 10.

Figure 10 Create your profile configuration.

4. On the Host tab, select Profiler for the Profiling Type you selected when configuring the application server, and verify the port number is 1470 for the Profiler.



5. On the Source tab, click the Add button and select Workspace Folder.

Figure 11 Select Workspace folder.

6. Click OK. 7. Select src folder from AddressBookWeb.

Figure 12 Select the src folder from the AddressBookWeb project.

8. Click OK. Click Apply. 9. Click Profile to start profiling.



Figure 13 Click Profile.

On the lower right of J Optimizer you will see a “Launching Tomcat 6” message, after which the Profiling Monitor displays <monitoring….collecting> J Optimizer Profiler.

Figure 14 Start messages. To view Profiler output, click the data view (Window | Show View) associated with the profiling tool you selected. For Profiler, select Memory view.

Figure 15 Select the Memory view.



Note: Use this next section only if you are attaching with a TPTP Connection.

Before attaching, make sure you have configured your TPTP connection to work with J Optimizer. To attach to the J Optimizer interface using a TPTP connection:

1. In the J Optimizer user interface, open the Profile Configuration Wizard (step 4.1 above). 2. In the left pane, select Attach - J Optimizer Agent and create a new configuration. 3. In the right pane, on the Host tab, select Use Agent Controller to attach to J Optimizer

agent. 4. Click on the Agents tab. 5. Click Refresh Data to display a list of available agents. Select the agent you want to use and

move it to the Selected Agents section. 6. Click Apply to save your selections, and Profile to start profiling. 7. Use one of the J Optimizer views associated with the profiling tool you used to view

profiling results. 8. Detach (Terminate) the J Optimizer agent from the Tomcat Server. 9. From the Profiling Monitor view, click the Terminate icon (■) to detach the J Optimizer

agent from collecting data.

10. Click Yes to Detach.

Stop (shutdown) the Tomcat server from J Optimizer. From Windows | Preferences | J Optimizer | Agent Configuration, select Tomcat 6 and click Stop. This shuts down the Tomcat server, as shown in Figure 16.



Figure 16 Shutting down the Tomcat server.

This concludes the basic steps to configure, start, stop and profile with J Optimizer for this tutorial. The next sections show how to use J Optimizer to identify different types of performance issues.



OVERVIEW OF THIS TUTORIAL This tutorial script is divided in sections, each one addressing a different type of performance issue using various tools included with J Optimizer.

First, this document uses J Optimizer Profiler tool to investigate three performance concerns:

• Excessive temporary object allocations • Memory leaks • Performance bottlenecks Secondly, this script shows how to use the new Analyze Snapshots tool to display and compare snapshots made at different times during the optimization process. This will allow developers and QA to easily see the benefits of using J Optimizer.

Third, we will see how you can use Code Coverage tool to make sure your unit tests exercise the tested code effectively.

The last section shows the Thread Debugger for various thread locking situations and to identify, analyze and predict thread locking.

You can complete the different sections in any order, although it makes sense to run the Profiler tutorials in the order described.

THE ADDRESS BOOK TEST APPLICATION You will see the tutorial script at work on a web application called the Embarcadero Address Book. It is a set of servlets that enables users to perform queries on a large XML file containing basic information about people. Users can find people based on their first and last names and their cities of residence. They can also add people to a temporary personal list. The list could be used to print the information known about the people listed. Once the session is closed any personal list is cleared.

In the AdddressBookWeb project provided, the application runs with Tomcat 6.0.14.

Xerces is the parser used for the XML part.



SCENARIO 1: EXCESSIVE TEMPORARY OBJECT

ALLOCATIONS This section demonstrates how to track down excessive allocations for temporary objects created when performing a request in the address book. We investigate and fix two problems. The first one deals with char array allocations, the second one with Integer objects.

EXCESSIVE CHAR ARRAY ALLOCATIONS This section discusses the aspects of excessive char array allocations using the following steps:

• Step 1: Run the application with the Profiler. • Step 2: Configure the Profiler for tracking temporary object allocations and run a

transaction. • Step 3: Find out where in the code the char arrays are created.

STEP 1: RUN THE APPLICATION WITH THE PROFILER. The address book is a web application that uses servlets to perform queries on an XML file that contains personal information.

We will start the application with the Profiler to investigate performance problems.

The Memory view of the J Optimizer Profiler appears (it’s the Java Heap view). It lists all the application’s classes and shows in real time how many instances of each you have.

You can save the results of this measurement in a snapshot file. You can use the Analyze Snapshots (Progress Tracker) tool to compare snapshots made under different conditions, so you can have hard evidence of the progress you are making as you optimize the code. You can use Analyze Snapshots to compare snapshots showing memory profiling, CPU profiling, code coverage or Request Analyzer measurements. We’ll start by saving a snapshot of the memory profile, so we can see evidence of progress as we reduce excessive object allocations.



We will generate a snapshot of Tomcat startup. Then run a transaction. Then compare the results of startup to our transaction.

1. Start Tomcat with J Optimizer Profiler attached (use either startup-with-optimizeit.bat from command line or click Start from Windows | Preferences | J Optimizer | Agent Configuration | Select Tomcat 6).

Figure 17 Start Tomcat with J Optimizer Profile attached.

2. Attach – J Optimizer Agent using Tomcat 6 from the Profile Configuration.

Figure 18 Viewing the Memory view.



3. After the Memory view is displayed, click the “Generate Snapshot” button in the Profiling Monitor view. Name the snapshot “Tomcat_Startup”, checking only the box to “Include Memory Profiler Data”.

Figure 19 Generate a new snapshot.

4. Open a Web Browser and enter: http://localhost:8080/AddressBookWeb/enter1

Figure 20 The Address Book home pages.




STEP 2: CONFIGURE THE PROFILER FOR TRACKING TEMPORARY OBJECT ALLOCATIONS AND RUN A TRANSACTION J Optimizer Profiler provides several features to investigate memory use in your application. Here we investigate how many objects are created when we run a transaction.

We set a mark by clicking the Mark button on the J Optimizer tool bar. Doing so resets the Heap view’s Diff column, and thereafter this column shows how many objects were created since we set the mark.

In the application we request a list of people named John. Once the request is performed we see the list (there are 33 persons matching “John”, the specified criteria.)

When we sort by difference, Diff., we see that more than 150,000 char arrays, char[], have been created since we set the mark.

Size shows how much memory all the objects consumed, about 15 Mb. The Size diff column shows the size of the objects created. We see that about 6 Mb of char arrays have been created since the mark.

1. Click the Mark button on the tool bar. 2. In the Embarcadero Address Book welcome page, type John in the First Name field then

press Start Search.

Figure 21 Search results for "John".



3. Once the request is done, click on the Diff header in the table to sort by difference.

Figure 22 Click the Diff header to sort results by differences.

4. Click “Generate Snapshot” button in the Profiling Monitor view. Name the snapshot “Snapshot_CHAR.snp”, checking only the box to “Include Memory Profiler Data”.

Figure 23 Generate a snapshot or the memory profile data.



STEP 3: FIND OUT WHERE IN THE CODE THE CHAR ARRAYS ARE CREATED The striking volume of memory use we just saw begins to suggest why it is important to try to reduce the number of temporary objects. In the Java programming language, dealing with objects is easy. When an object is not referenced anymore, the garbage collector automatically frees the memory allocated to it—but that convenience comes at a cost. In most Java virtual machines today, the garbage collector pauses all the other threads before it runs so your application is not doing anything productive while the garbage collector is running. The more temporary objects you create, the longer and more often the garbage collector runs and your application slows down. For that reason it is important to reduce the memory footprint when you can, by reusing objects or caching them, for example.

Now that we know we create a large number of char arrays, we need to discover which parts of the code are creating them so we can improve our memory management. We select the char[] line and switch to the Allocation Backtrace view. In this view, the upper tree shows the call graph of the methods responsible for allocating the char arrays. At the bottom, the table summarizes for any method that created some char arrays, the total number of arrays it created regardless of where it was called from. Before we look at the value, the Allocation Backtrace view will only show the objects created since we set the mark. That way we get information only for those objects created to satisfy the request we just ran.

At the top of the bottom table we see that the method AddressBookSAXHandler1.characters() created about 60% of the char arrays. Double-clicking that line opens the J Optimizer source code viewer in J Optimizer, which shows us the line of code that created the char arrays:

nodeValue += new String(ch, start, length);

When we browse the upper tree, we see that the call to the characters() method was made by the XML parser classes. Each is actually a SAX callback that we implemented to retrieve strings from the nodes in the XML file. The method creates a new string, and uses the String + operator, leading to the creation of new char arrays each time it is called. We can save storage if we merge the char arrays into a single string instead. A quick look at the javadoc for the String class tells us we should use a StringBuffer object that we can reuse across method calls, instead of creating new Strings. This is what we do in the next version of the address book.

We can still learn more from this view… The percentages we see in the tree and table are percentages of the total number of instances of char arrays. We can also get the percentages of memory used, which are especially useful when dealing with arrays. If, for example, you have 99 empty arrays and one large one, using the Allocation Count to find the large array will be very tedious because it will be reported as 1% of the total allocation, just like the others. Selecting Allocation Size will cause the large array to be reported as more than 90% of total allocations, making it very easy to spot.

We can also switch from the tree representation to a graph view (or aggregate view). The graph offers a different view of the Inspector information because every node appears only once. It allows you to zoom in and out, and change the level of details to reflect the precision you wish.

Note: Some may argue that refining your use of memory has become less important because some virtual machines now provide concurrent garbage collection (the application can continue executing while the garbage collector runs). Today, SDK’s equal or greater than SDK 1.4.1,



come with four types of garbage collectors. Only one of them, the concurrent Mark-Sweep Collector, executes “mostly concurrently” (some phases of the collection are performed while your application is running). The bottom line is that, whatever virtual machine you may be running, your code is going to run slower if you create more temporary objects than you need.

1. Right-click char[] in the memory view, then select the Allocation Backtrace. 2. Double-click the top line on the Allocations location (bottom table),

AddressBookSAXHandler1.characters(), to open the source code. 3. To show the Allocation Backtrace graph, at the top right corner of the Allocation Backtrace

view, click on the Aggregated view – Graph button . 4. From the Aggregated view – Graph, select AddressBookSAXHandler1.characters().This

will show the characters() method in bright red. The methods are colored based on the percentage of their allocation. Bright red methods are responsible for more of the allocation.

Figure 24 The Allocated Backtrace graph shows the methods that are responsible for more of the allocation.

The fix for the excessive allocation of array objects is implemented in the AddressBookSAXHandler2 class. We’ll see the result as we investigate the next problem.



EXCESSIVE INTEGER OBJECT ALLOCATION This section discusses how to find and fix excessive object allocation using the following steps:

• Step 1: Search for other excessive temporary allocations. • Step 2: Discover which parts of the code create the Integer objects. • Step 3: Check that we fixed the excessive allocation of temporary Integer objects.

STEP 1: SEARCH FOR OTHER EXCESSIVE TEMPORARY ALLOCATIONS Starting the new version of the address book, replacing the String + operator with a StringBuffer object that we can reuse across method calls, let’s see what we’ve already gained—and search for other excessive allocations of temporary object. From the Memory view we’ll

place a Mark and run the same request again with our new version.

First we see that this new version reduced the memory consumed by char arrays, char[], from about 6 Mb to about 1 Mb.

When we sort by Diff we see that the class with the most instances is now the Integer class; about 55,000 instances use more than 800 Kb of memory.

1. Stop the current profiling: click the Terminate red button on the Profiling Monitor view. 2. Shutdown the Tomcat Server (run shutdown.bat or click Stop from Windows | Preferences

| J Optimizer | Agent Configuration. Select Tomcat 6. 3. Start Tomcat with J Optimizer Profiler attached (use either startup-with-optimizeit.bat

from command line or click Start from Windows | Preferences | J Optimizer | Agent Configuration | Select Tomcat 6).

4. Attach – J Optimizer Agent using Tomcat 6 from the Profile Configuration. 5. Wait for the Memory view to update with profiling data. 6. Open web browser and enter: http://localhost:8080/AddressBookWeb/enter2

7. Click the Mark button on the tool bar. 8. In the web page that shows the Address Book welcome page, type John in the First Name

field, then press Start Search. 9. Once the request is done, click on the Diff header in the table to sort by difference. The

Integer class should be on top. 10. After the Memory view is displayed, save a snapshot of the memory allocations by pressing

the “Generate snapshot” button in the Profiling Monitor view. Save the file as “StringBuffer”, checking only the box to “Include memory profiler data”.




Figure 25 Memory view.

STEP 2: DISCOVER WHICH PARTS OF THE CODE CREATE THE INTEGER OBJECTS We use the Allocation Backtrace view again, this time to discover where the Integer objects are being created. We see that the method AddressBookSAXHandler2.startElement() is responsible for creating almost all of these objects, 99.92%. A thoughtful look at the code tells us that we create Integer objects so we can put some constants into a java.util.Stack object.

If we open the AddressBookSAXHandler.java file, we find that this class defines some int constants that are actually used to keep a state when parsing the XML file.

The application actually constructs new Integer objects as wrappers just to store those constants in a Java stack, because the Stack class can store instances of Object but not primitive types such as int.

C/C++ programmers would be likely to choose such an implementation because in C/C++ a simple case would probably make it easy to store an int in a stack object. For Java developers, a better way to proceed is to create Integer constants rather than a variable of type int in the first place, so the constants can be pushed in the stack object without using wrappers. AddressBookSAXHandler3.java implements this approach. The beginning of the file now defines Integer constants that can be pushed and popped directly.

1. Right-click the Integer class and select Allocation Backtrace.

Figure 26 Select Allocation Backtrace from the context menu.



2. Double-click the AddressBookSAXHandler2.startElement() in the bottom Allocation location box to open the AddressBookSAXHandler2.java file and highlight the lines of code that create the Integer objects.

Figure 27 Highlight the code that creates integer objects.

3. Open AddressBookSAXHandler.java. This file includes the int constants. Warning: make sure to select AddressBookSAXHandler.java and not AddressBookCacheSAXHandler.java!

Figure 28 The AddressBookSAXHandler.java file includes the int constants.



4. Now open AddressBookSAXHandler3.java the same way. This file features the new Integer constants that replace those memory-gobbling int constants.

Figure 29 New Integers.

STEP 3: CHECK THAT WE FIXED THE EXCESSIVE ALLOCATION OF TEMPORARY INTEGER OBJECTS We will now start a modified version of the AddressBook application to see whether we reduced the creation of Integers.

After running the request again and sorting by Diff we see that the Integer class does not appear at the top of the table anymore. If we want to find it, we can use the filter field at the bottom of the view.

We see that a request creates only 176 bytes of Integer objects compared with more than 800 Kb in the previous case.


| J Optimizer | Agent Configuration | Select Tomcat 6. 3. Start Tomcat with J Optimizer Profiler attached (use either startup-with-optimizeit.bat

from command line or click Start from Windows | Preferences | J Optimizer | Agent Configuration | Select Tomcat 6).

4. Attach – J Optimizer Agent using Tomcat 6 from the Profile Configuration. Wait for the Memory view to update with profiling data.

5. Open web browser and enter: http://localhost:8080/AddressBookWeb/enter3

6. Click the Mark button on the tool bar. 7. In the web page that shows the Address Book welcome page, type John in the First Name

field, then press Start Search. 8. Once the request is done, Sort by Diff. The Integer class should no longer appear at the top

of the table.




9. In the Filter field at the bottom of the view, type *Integer and press Enter. Only the few classes whose names end with Integer should show up.

Figure 30 Filter on class names that end with Integer.

10. Save a snapshot of the memory allocations by pressing the “Generate snapshot” button

in the Profiling Monitor view. Save the file as “Integer”, checking only the box to “Include memory profiler data”.

STEP 4: USE PROGRESS TRACKER TO VERIFY THAT WE FIXED THE EXCESSIVE OBJECT ALLOCATION Progress Tracker allows you to choose any two or more snapshot files (containing similar types of data) and compare them, so you can see how your optimizations have affected (1) memory allocations, (2) CPU usage, or (3) code coverage. You should get in the habit of taking snapshots as you progress through the optimization process. You can then use Progress Tracker to verify that you are making progress, and you can use screen shots of Analyze Snapshots to document that progress.

You must always begin by giving Progress Tracker the location of the folder containing you snapshot files, so we’ll click on the “Open snapshot directory” button on the toolbar. We can then see our collection of snapshot files, with small icons indicating the type of data stored in each snapshot.

We want to compare the results of Steps 4 and 6 in Scenario 1, so we’ll compare snapshots “CHAR” and “STRINGBUFFER” by choosing them from the list of snapshots.

We can compare overall object allocations, and we can compare object allocations for each method.

1. From the J Optimizer perspective, click the “Open multiple snapshots for analysis” icon.

2. Click on the Browse snapshot directory button and select the folder containing the snapshot files. The Snapshot list window will then appear.

3. Select snapshot “CHAR” and snapshot “STRINGBUFFER” and then click the OK button.



4. After a short processing delay for, you will see data in the Progress Tracker view. Click on

the “Memory” tab to display the comparison of memory allocations for the two snapshots.

5. Click the “Total Object Allocation Count” tab to compare the number of objects allocated in the two snapshots.

6. Click the “Total Object Allocation Size” tab to compare object allocations for each method.

Repeat the same for comparing “STRINGBUFFER” with “INTEGER” snapshots. For this comparison you should see that there are 54948 less Integer objects allocated in the “INTEGER” snapshot that there were in the “STRINGBUFFER” snapshot.

THE APPLICATION IS NOW FAR MORE SCALABLE A few easy steps reduced the memory footprint of one request by 2.5 Mb for the char arrays and 800 Kb for the Integers, or a total of 3.2 Mb—and that’s 3.2 Mb of objects that didn’t require garbage collection, so performance improved as well. Because it uses less memory the application can handle more requests with shorter response time.

We can expect the server will receive hundreds of requests at the same time. These optimizations have made our application truly scalable!



SCENARIO 2: SOLVING MEMORY LEAKS

This section introduces the term memory leak as it’s used in the Java world. We then investigate a memory leak in our application using two different methods. The first uses the same approach as in above Scenario 1, which requires us to use the Memory view (Heap view) and the instance and reference graphs view. The second method shows how we can achieve the same results more quickly by using the Automatic Memory Leak Detector in J Optimizer.

WHAT ARE MEMORY LEAKS IN JAVA? In most languages that compile to native code, such as C/C++, it is the developer’s task to free memory objects that are not used anymore. If the developer forgets to free an object, it continues to consume memory. If many objects are leaked, the process may run out of memory.

Because every Java Virtual Machine (JVM) features a garbage collector, this type of memory leak cannot happen in Java applications. Once an object is not referenced anymore, the garbage collector frees the memory it used. So are Java applications free of memory leaks? Not really. An object may not be used anymore but still have a reference somewhere that the developer is unaware of. A simple example would be a cache that is not flushed completely (some objects remain after flushing the cache). The cache will grow bigger as it is used, and will prevent garbage collection of the objects it references.

SYMPTOMS OF MEMORY LEAKS Memory leaks usually do not affect the application during the first few hours of running.

As the leaking code is being executed, leaked objects use more memory. The Java heap is bigger which makes the job of the garbage longer. Since less memory is available as well, the garbage collector kicks in more often. So the garbage collector starts to run more often and for longer periods of time. Since in most virtual machines today the garbage collector pauses all the threads when it runs, the application starts being less responsive as the Java heap is getting filled with leaked objects. At some point the application becomes irresponsive because it spends all of its time garbage collecting. At this point the virtual machine needs to be restarted.

If this is an inconvenience for client applications, it can be a major problem for server side applications that needs to be run constantly. Memory leaks are often a tough problem to investigate since they may start being noticeable only under load after some time. They are extremely difficult to track down without a tool like J Optimizer.

INVESTIGATING MEMORY LEAKS WITH THE MEMORY AND INSTANCE VIEWS We begin our search for memory leaks by profiling the most recent version of Address Book, the one that fixed the allocation problems.

We first run the garbage collector so we remove any object that could be garbage-collected and then we set a mark. We can now perform a full session in our application to hunt for potential memory leaks.



We then look for all persons named John. In the result page we see that we have a link that allows adding a person to “my contacts”. This feature lets you perform several requests and add persons to a personal list stored in your session, which you can then print, save to disk, and so on. Once you close your session the list is discarded.

Clicking “Add all persons to contacts” adds all the persons named John to our list.

We then issue another request, this time for people named Keith. We add all those people to our contact list, display the contact list, and close the session.

At this point, we come back to J Optimizer, run the garbage collector, and sort by Diff. We see in the Diff column that in response to our request, the application has created more than 800 instances of String that have not been garbage-collected.

Therefore, there are potential memory leaks.

This section discusses how to find and fix memory leaks using the Memory and Instance views and uses the following steps:

• Step 1: Look for leaked objects in a session • Step 2: Investigate the potential leaked Strings • Step 3: Run the fixed version

STEP 1: LOOK FOR LEAKED OBJECTS IN A SESSION 1. Stop the current profiling: click the Terminate red button on the Profiling Monitor view. 2. Shutdown the Tomcat Server (run shutdown.bat or click Stop from Windows | Preferences

| J Optimizer | Agent Configuration | Select Tomcat 6. 3. Enable Garbage Collector by setting disableGC=”false” in the optimizeit.xml file. Look for

this line: <memory-profiler enabled="true" reportCollectedObjects="true" disableGC="false"/>


5. Select Attach – J Optimizer Agent using Tomcat 6 from the Profile Configuration. 6. Wait for the Memory view to update with profiling data. 7. Open web browser and enter: http://localhost:8080/AddressBookWeb/enter3 8. Wait for the Address Book welcome page to show up. 9. From the Profiling Monitor view, force garbage collection by pressing the Run Garbage

Collection button a few times. 10. Click the Mark button on the tool bar, and then wait until the Diff column reports None. 11. In the Address Book welcome page, type John in the First Name field, then press Start

Search.



12. In the page listing the people named John, click Add all persons to contacts.

Figure 31 Search for John Adams.

13. Click on the Back to search link to come back to the search page. 14. Type Keith in the first name field, and then press Start Search. 15. In the page listing the people named Keith, click Add all persons to contacts. 16. Click Show my contact list to see all the persons currently in your list (you should see 73

persons, all the John and Keith persons). 17. Click Close my session.

18. Force garbage collection by pressing the Run Garbage Collection button a few times. 19. Sort by Diff by clicking the Diff column. You should see that more than 800 instances of

String have survived garbage collection, even though they are no longer in use.

Figure 32 Memory view shows 800 instances of String that survived garbage collection.



STEP 2: INVESTIGATE THE POTENTIAL LEAKED STRINGS Now that we know that some String objects may represent memory leaks, we need to understand why those objects were not garbage-collected.

To that end, we use the Instance References View. This view shows in the top table all the instances of the selected class. The Description column shows the toString representation for each instance—in the case of a String object, it’s the contents.

We find that several Strings contain personal information: names, street addresses, cities, phone numbers, etc. If we select such a String, J Optimizer displays in the middle view the reduced reference graph for that specific instance.

When we look at the tree, we see that this String is actually referenced by a Location object, from its address member variable. This Location object is itself referenced by an Object array, the Object array is referenced by a Vector, and the Vector is referenced by a Person object from its locations member variable. The Person object is referenced by an Object array, part of PersonList object, which is referenced by a ListenerElement object, and so on.

If we could remove any reference from that chain, the String selected in the top table would be garbage-collected. This graph lets us understand what’s happening. The PersonList object references some Person objects which contain some Location objects. All these Person objects are not garbage collected because the PersonList is still referenced by a ListenerElement.

The PersonList contained the people found in our two search requests. When we closed the session, we might have expected that the PersonList would be unreferenced. In order to understand why this ListenerElement is still referencing the PersonList, we select the ListenerElement in the tree. The bottom table shows the stack traces of the methods responsible for the allocation of the selected object, here the ListenerElement. Selecting the first line shows the AddressBook.addListener() methods that created the ListenerElement; selecting the second line shows which line of code actually calls addListener(). The source code viewer highlights the line that made that call.

When the SearchServlet creates the PersonList, it adds an AddressBook listener to this PersonList so the PersonList can be updated to reflect changes to the personal data in the AddressBook.

When we close the session, we don’t remove the PersonList from the AddressBook listener. Therefore the PersonList cannot be garbage collected.

1. Right-click the java.lang.String line in the Memory view then select Instance References. 2. In the top Instances Of list select a line which shows a street name (such as Johnson Blvd.). 3. In the Reduced Reference Graph view select the line starting with addressBookListener of

com.codegear.addressbook.AddressBook$ListenerElement.



4. In Allocation Backtrace view select the AddressBook.addListener()(addressBook.java:157) line; the J Optimizer source viewer displays the class and highlights the line which caused the leak: listeners.addElement(new ListenerElement(AddressBookListener.class,abl));

Figure 33 The Allocation Backtrace view allows you to drill down to the line of code that is causing the memory leak.

5. Save a snapshot of the memory allocations by pressing the “Generate snapshot” button

in the Profiling Monitor view. Save the file as “PersonList”, checking only the box to “Include memory profiler data”.



STEP 3: RUN THE FIXED VERSION We now run a fixed version of the application that actually removes the PersonList from the AddressBook listener when the session is closed.

In the end, we see that we have only about 100 Strings remain compared to 800 earlier.

If we were to investigate further we would find out that the remaining survivors are either class constants or values cached by Tomcat.

1. Follow the same procedures as in 1: Looking for leaked object in a session, to stop and start, we now use the application that starts with the memory leak fixed.

2. Open web browser and enter: http://localhost:8080/AddressBookWeb/enter4 3. Wait for the Embarcadero Address Book welcome page to show up. 4. From the Profiling Monitor view, force garbage collection by pressing the Run Garbage

Collection button a few times. 5. Click the Mark button on the tool bar. 6. Then wait until the Diff column reports None. 7. In the J Optimizer Web View that shows the Embarcadero Address Book welcome page,

type John in the First Name field, and then press Start Search. 8. In the page listing the people named Jay, click Add all persons to contacts. 9. Click on the Back to search link to come back to the search page. 10. Type Keith in the first name field then press Start Search. 11. In the page listing the people named Keith, click Add all persons to contacts. 12. Click Show my contact list to see all the persons currently in your list (you should see 73

persons, all the John’s and Keith’s). 13. Click Close my session. 14. From the Profiling Monitor view, force garbage collection by pressing the Run Garbage

Collection button a few times. 15. Sort by Diff. Note the reduction in the number of surviving Strings. 16. Save a snapshot of the memory allocations by pressing the “Generate snapshot” button

in the Profiling Monitor view. 17. Save the file as “PersonList_FIX”, checking only the box to “Include memory profiler

data”.




INVESTIGATING THE MEMORY LEAK WITH THE AUTOMATIC MEMORY LEAK DETECTOR This section of the tutorial teaches you how to find a memory leak with the Automatic Memory Leak Detector and verify that you fixed it using the Progress Tracker.

This section includes the following steps:

• Step 1: Find the memory leak • Step 2: Use Progress Tracker to verify that we fixed the memory leak

STEP 1: FIND THE MEMORY LEAK J Optimizer provides a really powerful tool that tracks down memory leaks in no time. It is called the Automatic Memory Leak Detector (AMLD). It works by comparing different states of the Java heap and by looking for objects whose number of references has grown. It is especially useful for tracking down memory leaks, but can also used in several other situations in which you want to investigate memory growth in your application; for example, when studying cache strategies.

In this step we see how much easier the AMLD makes it to track down the memory leak we traced earlier. We run the Embarcadero Address Book version that includes the memory leak. (2 – Reducing excessive creation of Integers)

Before starting to perform a request, we switch to Memory Leak Detector view. It generates a first heap state. Then we perform our usual request, add all the persons named John to our personal list and close the session.

At this point, we generate a second heap state.

The two top tables list the different heap states available. The Information displayed elsewhere in the view is built by comparing the heap states selected in the two tables.

The table in the middle of the view lists objects whose number of references has grown between the first heap state and the second. The Count column actually displays the number of new references that the object has (directly or transitively). Objects with a large number of new references are likely to represent memory leaks. If we select any object from that list, J Optimizer displays a graph of the object in the bottom part of the view, the list of reference to its root(s) on the left, and all the new references and referenced objects on the right.

In our case we select the object at the top of the list, which appears to be a Tomcat object. By looking at the graph, we quickly find that this object references one address book servlet which references the address book, and that through the address book listener Vector it’s holding on to a PersonList object containing all the persons added to the person list during the session. We find our memory leak in no time.



Note that here the ListenerElement responsible for the memory leak does not appear at the top of the middle table, because this session represented the first time this servlet was loaded and instantiated. If we perform another similar session and save a new heap state, the Object array of the PersonList responsible for the memory leak appears at the top of the table. In most cases you can actually refine the information by generating several heap states.


| J Optimizer | Agent Configuration | Select Tomcat 6. 3. Disable Garbage Collector by setting disableGC=”true” in the optimizeit.xml file. Look for

this line: <memory-profiler enabled="true" reportCollectedObjects="true" disableGC="true"/>.


5. Attach – J Optimizer Agent using Tomcat 6 from the Profile Configuration. 6. Wait for the Memory view to update with profiling data. 7. Select Window | Show View | Memory leak detector. 8. Open a web browser and enter: http://localhost:8080/AddressBookWeb/enter3 9. Wait for the Embarcadero Address Book welcome page to show up. 10. Wait for Heap Used to be displayed (such as 3394KB) on Memory leak detector. 11. In the Embarcadero Address Book welcome page, type John in the First Name field, then

press Start Search. 12. In the page listing the people named John, click Add all persons to contacts. 13. Click Close my session. 14. Generate a new heap state by pressing the Save Heap State button. 15. The top line in the middle table should be StandardWrapper from an Apache package.

Select the next line, Object [ ].




The tree at the bottom shows a graph for the selected Object [ ]. Scroll to the right and you easily find that this standard wrapper references the SearchServlet and that it references the AddressBook, which references a PersonList, which references several Person objects. Leave the mouse over a Person object to reveal a tool tip that provides information about the object.(toString representation, number of references directly and transitively created, etc.).

Figure 34 The Memory Leak Detector provides details about the objects that are leaking.



STEP 2: USE PROGRESS TRACKER TO VERIFY THAT WE FIXED THE MEMORY LEAK We want to compare the results of Steps 2 and 3 in Scenario 2, so we’ll compare snapshots “PersonList” and “PersonList_FIX” by choosing them from the list of snapshots.

We can now see that the AddressBookSAXHandler3.endElement() method allocates 32,920 less objects than it did before!

1. From J Optimizer Perspective, click the Progress Tracker tool from menu bar.

Figure 35 Open the Progress Tracker tool.

2. Browse to Snapshot directory and select snapshot “PersonList” and “PersonList_FIX” and then click the OK button.

3. After a short processing delay for, you will see data in the Progress Tracker view. If necessary, click on either “Allocation Count” or “Allocation Size” tab to display the comparison of memory allocations and object allocations for the two snapshots.

Figure 36 Compare memory allocations of two snapshots.



SCENARIO 3: IDENTIFYING BOTTLENECKS In this section we demonstrate how the J Optimizer CPU Profiler allows you to pinpoint bottlenecks in your code quickly.

These steps walk you through finding out where time is spent doing a task and examines two caching solutions: a flat cache and using hash tables.

Note: The results of the following steps depend a lot on which JDK and application server you are using. The presented results have been seen using Tomcat 6.0 with JDK 1.5. Find out where the time is spent when we perform a request on the A

STEP 1: DETERMINE WHERE TIME IS SPENT WHEN WE PERFORM A REQUEST ON THE ADDRESS BOOK When an application is slow, it is usually only a few methods that are using most of the time. Once the developer knows which part is slow, it is generally easy to modify the code so the application is faster. The hard part is to find which methods are the slow ones.

In this step we try to reduce the time needed to perform a request in the Address Book.

Because we now want to focus on the CPU profiler, we start the Address Book with the memory profiler disabled. Both profilers can be used simultaneously, but disabling the memory profiler reduces overhead.

The CPU profiler in J Optimizer is very easy to use. It works like a tape recorder.

We just press Start, then go to the search page and search for a specific person. Once the request is done, we stop the CPU profiler, and it shows us where the time was spent during the recorded session.

The table at the bottom shows the Hot spots, the methods that used most of the time. We see that about 75% of the time was spent in the XML classes, which parse the XML file.

Each time we perform a request, we parse the Address Book XML file to find persons matching the specified criteria. The CPU profiler shows that this is a fairly expensive process.

If we want to improve the response time, we could parse the XML file once and cache its contents.

We could then browse through the cache for persons matching the criteria, without having to parse the XML file again. This approach uses some memory because the XML file is big, but the cache should remain in memory for a long time, and most virtual machines (such as HotSpot) know how to deal efficiently with long-lived objects.



In the next version we read the XML file when the Address Book is created and store the persons contained in the XML file in a Vector. When handling a request, the application iterates through the Vector to find the persons matching the specified criteria.


| J Optimizer | Agent Configuration | Select Tomcat 6. 3. Enable Garbage Collector, Auto-Start CPU and disable Memory Profiling by setting in

optimizeit.xml:

disableGC=”false” auto-start-CPU enabled="true" memory-profiler enabled="false" Note: These changes can also be made from the Edit | Agent Configuration screen.


5. Attach – J Optimizer Agent using Tomcat 6 from the Profile Configuration. 6. Wait for the Memory view to update with profiling data. 7. Tomcat will now start with the CPU Profiler. 8. Open the CPU Profiler view by selecting Windows | Show View | CPU. 9. J Optimizer should now show the CPU profiler view (we disabled the memory profiler for

this runtime configuration). 10. Open web browser and enter: http://localhost:8080/AddressBookWeb/enter5 11. Wait for the Embarcadero Address Book welcome page to show up.




12. Set CPU options using the CPU profiler button; . Set CPU option to Instrumentation, Percussion=microseconds, the option Only record CPU usage is selected, and select Start CPU recording when dialog is closed, as shown in Figure 37.

Figure 37 Set CPU options.

13. Click OK. 14. The CPU profiler should start recording data. If not start the CPU recording by pressing the

Start/Stop CPU profiler button. 15. In the Address Book search page enter Al for the First name, Mannarino for the Last name

and New York for the City (you can specify any other person in the address book; just make sure you specify all three criteria), then press Start search.

16. When the page displaying the results shows up, stop the recording by clicking the Start/Stop CPU profiler button again.

17. Click “Select Busiest Thread” button. This should be “main”. 18. Double-click on “main”. The CPU profiler should show the tree view. The graph view is

usually better for a tutorial. To switch to it, click the Aggregated view - Graph button . 19. Leave the cursor over the red node. The tool tip text shows that more than 90% of the time

is spent in Tomcat (XML classes and the methods) it invokes.

20. Save a snapshot of the CPU usage by pressing the “Generate snapshot” button in the Profiling Monitor view. Save the file as “CPU”, checking only the box to “Include CPU profiler data”.



STEP 2: USE A FLAT CACHE Here we run a version of the application that caches the XML file in a Vector. We start the CPU profiler and perform the same request. The page now displays much faster (Results will be different on your machine. On the machine used to develop the application the request took about 180ms with the flat cache as against 3s without it.)

Now when we look at the tree we see that most of the time is spent in the AddressBook5.findPerson() method, which, including the time spent in the methods it calls, uses more than 50% of the total time. In the Hot Spots table we see that the method AddressBook5.findPersonsFromCity() uses more than 20% of the time, so it is probably a good place to start improving the code.


| J Optimizer | Agent Configuration | Select Tomcat 6. 3. Use same settings as last steps (disableGC=”false”, auto-start-CPU

enabled="true" memory-profiler enabled="false").

Note: These setting changes can also be made from the Edit | Agent Configuration screen.


5. Attach – J Optimizer Agent using Tomcat 6 from the Profile Configuration. 6. Wait for the Memory view to update with profiling data. 7. Tomcat will now start with the CPU Profiler. 8. Open the CPU Profiler view; Windows | Show View | CPU. 9. J Optimizer should now show the CPU profiler view (we disabled the memory profiler for


12. Set CPU options using the CPU profiler button; . Set CPU option to Instrumentation, Percussion=microseconds, the option Only record CPU usage is selected, and select Start CPU recording when dialog is closed.


Start/Stop CPU profiler button. 15. In the Embarcadero Address Book search page enter Al for the First name, Mannarino for

the Last name and New York for the City (as before, you can specify any other person in the address book, so long as you specify all three criteria), then press Start search.

16. When the page displaying the results shows up, stop the recording by clicking the Start/Stop CPU profiler button.




17. Position the cursor over the findPerson() node. The tool tip text should show that this method used more than 50% of the time, as shown in Figure 37.

Figure 38 Examine the findPerson() node.



STEP 3: USE HASH TABLES FOR CACHING Taking a quick lock at the Implementation of findPersonsFromCity(), we find that it actually iterates through the entire cache for any person matching the specified city.

We conclude that a trio of cached Hashtables is a much better data structure. In one table, keys are city names, and values are Vectors of persons from that city, so the application will not need to search through all persons. In the other two tables, first name and last name are the keys.

The next version implements the three caches. Each allows retrieval of a list of persons from a single field: first name, last name, or the city of residence.

Here we profile the same request with the version that caches three Hashtables. The results show that the application is now very fast (on the development machine, response time dropped further, from 180ms to about 30ms). Most of the time is now spent in the application server classes, or in classes they use (such as SocketOutputStream, PrintWritter, and so on).

Our application now uses resources very efficiently. We have reduced the time to perform a request from a couple of seconds to a few milliseconds. The application is now very scalable and can be deployed.


| J Optimizer | Agent Configuration | Select Tomcat 6 3. Use same settings as last steps (disableGC=”false”, auto-start-CPU enabled="true"

memory-profiler enabled="false") Note: These setting changes can also be made from the Edit | Agent Configuration screen.


5. Select Attach – J Optimizer Agent using Tomcat 6 from the Profile Configuration. 6. Wait for the Memory view to update with profiling data. 7. Tomcat will now start with the CPU Profiler. 8. Open the CPU Profiler view; Windows | Show View | CPU. 9. J Optimizer should now show the CPU profiler view (we disabled the memory profiler for


12. Set CPU options using the CPU profiler button; . Set CPU option to Instrumentation, Precision=microseconds, the option Only record CPU usage is selected, and select Start CPU recording when dialog is closed.


Start/Stop CPU profiler button. 15. In the Address Book search page enter Al for the First name, Mannarino for the Last name

and New York for the City (as before, you can specify any other person in the address book, so long as you specify all three criteria), then press Start search.




16. When the page displaying the results shows up, stop the recording by clicking the Start/Stop CPU profiler button.

Figure 39 View search results.

Note: You may notice that the results don’t show the code of the address book anymore. By default, the CPU profiler filters methods that use less than 1 ms. We may get to see the methods, since we set Precision=Microseconds. You can also select Disable filter if you don’t want methods filtered at all. If you take either of these options, you’ll find that AddressBook6.findPerson() uses a negligible amount of time.

17. Save a snapshot of the CPU usage by pressing the “Generate snapshot” button in the Profiling Monitor view.

STEP 4: USE PROGRESS TRACKER TO VERIFY THAT WE REDUCED THE CPU USAGE We want to compare the results between “No caching” and “Using Hash tables for caching” in Scenario 3, so we’ll compare snapshots “CPU” and “HashTable”.

See how time in XML classes went from 1.8 seconds to approximately zero, and time in AddressBookSAXHandler3 went from 0.9 seconds to approximately zero.

1. From the J Optimizer Perspective, click the Progress Tracker tool from menu, as shown in Figure 39.

Figure 40 Click the Progress Tracker tool.

2. Browse to Snapshot directory and select snapshot “CPU” and “HashTable” and then click the OK button.

3. After a short processing delay for, you will see data in the Progress Tracker view. If necessary, click on the CPU tab. Then select CPU Times and Threads tabs to display the comparison of CPU utilization for the two snapshots, as shown in Figure 41.



4. See how we have dramatically reduced the CPU usage for the XML classes, and for the AddressBookSAXHandler3 class.

Figure 41 Compare the CPU utilization for the two snapshots.



SCENARIO 4: IMPROVING CODE QUALITY WITH

CODE COVERAGE When testing an application, it is vital to ensure that the tests exercise the code fully. If part of the code is not tested, bugs may remain in the final application. This policy is especially important when doing unit testing. A developer writing tests for a single class must make sure they actually test the class thoroughly.

This section shows how to improve code quality using a unit test.

RUN A UNIT TEST WITH CODE COVERAGE The developer that wrote the Address Book wrote a number of unit tests to make sure the application works as expected. Here we look at the one that tests for the AddressBook6.findPerson() method. As you’ve seen, this method finds people in the cache that match a specified first name, last name, or city, or any combination.

When the developer ran this test, the method passed successfully. In this step we run the same test with Code Coverage to learn whether it fully exercises the method.

When we do, Code Coverage’s class view shows us the list of classes that have been exercised, and to what extent. We see that AddressBook6 has been exercised at 67.46%, indicating that a third of its code has not been exercised. When we select this class and switch to the method view, we get the coverage for each method of the AddressBook6 class. We see that findPerson() has been tested at 81.63% [eight lines (lines 60 – 67) have not been executed]. When we select this method in the table, the Code Coverage source viewer shows the code for the method, with lines that have been executed highlighted in yellow. We see that the block between lines 60 and 67 has not been executed at all. We note that the comment indicates that this block handles the case in which the method is called with a last name but no first name.

With the untested code identified, we can return to the test and add code that exercises the untested case.


| J Optimizer | Agent Configuration | Select Tomcat 6. 3. Set the OISELECTOR to Code Coverage

Figure 42 Select Code Coverage.

4. In the optimizeit.xml file, set Pause on Exit and Generate Snapshot on Exit:

<code-coverage pauseOnExit="true" snapshotOnExit="true"



5. Start Tomcat with J Optimizer Code Coverage attached (use either startup-with-optimizeit.bat from command line or click Start from Windows | Preferences | J Optimizer | Agent Configuration | Select Tomcat 6).

6. Verify Console says: J Optimizer Code Coverage Agent enabled Port 1472 7. Modify Profile Configuration for Tomcat 6 for Code Coverage and Port 1472, as shown in

Figure 40.

Figure 43 Configure your profile.

8. Click Profile to Attach – J Optimizer Agent using Tomcat 6 with Code Coverage. 9. In J Optimizer Perspective, Window | Show View | Class Coverage. 10. Run JUnit test, TestAddressBook6 with Code Coverage.

• Select Profile | Open Profile dialog.

Figure 44 Right-click to select the Open Profile dialog.

• In Test tab, Create a new JUnit Test for com.codegear.addressbook.TestAddressBook6 in Project AddressBook.

• In Profiler tab, select Code Coverage and check Pause on Exit and Generate Snapshot on Exit.

• Click Apply. • Click Profile.

11. JUnit test TestAddressBook6 will execute with Code Coverage and results displayed on Class Coverage view .

12. TestAddressBook6 class will show 100% coverage.

13. Double-click on TestAddressBook6 to open Method coverage view .



14. Click on testFindPerson()in the top table, and the source code viewer will jump to that method in the code.

15. Save a snapshot of the code coverage by choosing “Generate Snapshot…”Save the file as “CodeCoverage”.

SCENARIO 5: THREAD DEBUGGING The Address Book project includes a code example ThreadDExample that simulates various thread locking situations. For this tutorial scenario, we’ll use this ThreadDExample sample program.

This scenario shows how to debug thread locking situations using the following steps:

• Step 1: Run the thread debugging example • Step 2: Analyzing and predicting thread locks • Step 3: Eliminating “Random” thread locks

STEP 1: RUN THE THREAD DEBUGGING EXAMPLE Let’s go ahead and launch this ThreadDExample application with the J Optimizer Thread Debugger. We now get a view of the threads.

• Green means the thread is running. • Purple means it’s waiting in I/O. • Red means the thread is waiting. • Yellow means the thread is blocked.

So let’s run the big thread lock contention example and see what happens. We see that the new threads show up and are yellow because of thread locking.

Let’s select one of the threads and click on the yellow bar icon to find out exactly where the thread is in contention to acquire a monitor. We can then also view all the contended monitors and get details on the contentions.

Note that we can select any time interval, and find out specifically what was happening. This provides an advanced thread-debugging environment that makes a powerful complement in J Optimizer.

Run the ThreadDExample application with J Optimizer Thread Debugger.

Note: We do not need Tomcat running for this scenario. 1. Stop the current profiling: click the Terminate red button on the Profiling Monitor view. 2. Shutdown the Tomcat Server (run shutdown.bat or click Stop from Windows | Preferences

| J Optimizer | Agent Configuration | Select Tomcat 6 3. Select Window | Show View | Threads.



4. Select Profile | Profile Configurations.

Figure 45 Right-click and select Profile Configurations.

5. Create New Java Application profile. Select com.codegear.addressbook.ThreadDExample from AddressBook project as the Main class. Select Thread Debugger and “Pause on Exit” from the Profiling tab.

Figure 46 Select com.codegear.addressbook.ThreadDExample as the main class.

6. Click Apply and Click Profile. 7. Both the ThreadDExample and the ThreadDebugger should now be running. From the

Console view, select 1 and press Enter, then switch to the Thread Debugger. 8. Select one of the new threads which are highlighted with yellow, and press on the yellow

bar icon on the top. 9. Double-click on the ContentionExample$Consumer.run() method to go right to the source

code to uncover the problem.



10. Click on the first contended monitor on the bottom left pane, and view the contention details.

Figure 47 View contention details.



STEP 2: ANALYZING AND PREDICTING THREAD LOCKS J Optimizer Thread Debugger provides the means to both identify and predict thread locking. We can initiate a major thread lock from our example, and select the Monitors view to analyze the deadlocks. The resulting diagrams show the details necessary to debug the thread locking. The diagrams link together the thread monitors and which threads own them so that we can track down the lock.

1. From the Console view, select 3 and press enter, and switch back to the Thread Debugger. 2. Select Window | Show View | Monitors view. 3. Walk through the diagram to show how they work together, as shown in Figure 45.

Figure 48 View the Monitors diagram.



STEP 3: ELIMINATING “RANDOM” THREAD LOCKS A key feature of J Optimizer Thread Debugger is its ability to predicatively review your code and generate warning reports so you know immediately where the problem areas are. Often the thread locking appears somewhat random, and debugging can become frustrating. The right answer is to use the Monitor Usage Analyzer and record the threading. We then have a snapshot and we can explore the problem and reproduce it.

The reports that are produced from the recorded session are linked to the source code and allow one to both analyze and predict possible locks.

1. From the Console view, hit return to stop the deadlock example. 2. Select Window | Show View | Lock Analyzer (its icon is the scroll with green check mark). 3. On the Lock Analyzer view, click the “start recording” icon. 4. From the console, select 3 and press enter, and switch back to the Lock Analyzer. 5. Click Stop recording. 6. Double click on any of the locking occurrences to view the detailed report, as shown in

Figure 49.

Figure 49 View the detailed report of a thread lock.

7. Restart Monitor Usage Analysis. 8. On the Lock Analyzer view, click the “start recording” icon. 9. From the console, select 4 and press Enter, and switch back to the Lock Analyzer. 10. Click Stop recording.



11. Double click on any of the locking occurrences to view the detailed report.

Figure 50 View a detailed report of a thread lock.



CONCLUSION: KEY DIFFERENTIATORS OF J

OPTIMIZER Several key factors differentiate J Optimizer from all competitors in the arena of performance management.

PRODUCTIVITY BENEFITS J Optimizer provides productivity-enhancing capabilities that extend beyond any other performance solution available today. A key example is the new Probe Insertion, which allows users to add java code fragment into the running java application at runtime.

Other new key capabilities include:

• Advanced Code Metrics • Advanced Code Audits • J Optimizer Progress Tracker is now fully integrated (allows for analyzing snapshots so users

can compare profiler, code coverage, and request analyzer snapshots. It also generates reports that can be exported in PDF and HTML format.)

• CPU Profiler Root Filtering (automatically start collecting data when specified methods are entered, and then stop collecting data when those methods exit).

• Probe Insertion (add Java code fragments into an application at runtime (used in the Profiler and Request Analyzer only. The following method probe fragment types are supported: catch, entry, executableUnit, exit, and staticInitializer).

• JVMTM Tool Interface (JVMTI). Replaces JVMPI and JVMDI used in older JDKs. Used to profile using JDK 5 and above.

• Remote Attach to J Optimizer Agent (Users can install J Optimizer agent on a remote system running an application or application server. This allows for the results from the remote system to be profiled in the J Optimizer IDE).

• EJB 3 support for Request Analyzer • Branch coverage (Code Coverage) • Unit test snapshot generation. Performance (memory and cpu) data is gathered and

automatically stored in a snapshot for each test. • TPTP ProbeKit • JDK 6 and Java EE 5 support. • Solaris, Linux, Windows and Mac OS X support. • Eclipse Web Tools Platform (WTP) integration.



EASE OF USE The unique graphical interface and powerful features of J Optimizer have been specifically designed for everyday use throughout the development process. Regularly run quick, informal performance checks on newly developed features; see in real time how code is executed and detect performance problems. Features include:

• Simple installation process features plug-and-play startup • Scalable call graphs provide easy-to-understand visualization • Real-time views display how code is executed

TIGHT INTEGRATION WITH ECLIPSE BASED IDES The seamless integration of J Optimizer with Eclipse based IDEs makes J Optimizer the solution of choice. Both developers and QA are now able to access a complete performance-management solution.

TRULY SCALABLE The J Optimizer quickly scales to test any Java environment including the most intensive J2EE applications. J Optimizer achieves its exceptional scalability in the following ways:

• Unique CPU sampling and instrumentation options • Just-in-time Data Fetcher • Lean architecture

LOW OVERHEAD The overhead caused by J Optimizer Profiler is significantly less intrusive than that of other solutions. Using J Optimizer Suite therefore enables you to:

• Minimize distortion of profiling results • Create a realistic test environment • Profile anywhere even in production

J Optimizer delivers advanced, easy-to-use features and extreme scalability. Either as a standalone profiling tool or a tight integration with Eclipse based IDEs makes it is the solution of choice for developers and QA to access a complete performance management solution directly from their development and/or QA environment.

.

Embarcadero Technologies, Inc. is a leading provider of award-winning tools for application developers and database professionals so they can design systems right, build them faster and run them better, regardless of their platform or programming language. Ninety of the Fortune 100 and an active community of more than three million users worldwide rely on Embarcadero products to increase productivity, reduce costs, simplify change management and compliance and accelerate innovation. The company’s flagship tools include: Embarcadero® Change Manager™, CodeGear™ RAD Studio, DBArtisan®, Delphi®, ER/Studio®, JBuilder® and Rapid SQL®. Founded in 1993, Embarcadero is headquartered in San Francisco, with offices located around the world. Embarcadero is online at www.embarcadero.com.

http://www.embarcadero.com/

Documents

Embarcadero J Optimizer Tutorial...1. Remote Attach using the J Optimizer Agents. You can run the application on a remote machine or local machine. On the remote machine, you run the