NetBeans IDE 4.1/5.0 Profiler Tutorial

Background Information:

The Swing library provides graphical user interface components for J2SE applications. Multiple threads are used by the Swing library and the NetBeans Profiler is a powerful tool that can be used to understand the amount of processing that occurs on each thread. This understanding can be used to solve performance problems.

Steps to follow:

1. Choose File > Open Project. Navigate to the <tutorial_root>/netbeansprofiler/exercises folder. Select the exercise1 folder and click the Open Project Folder button.
2. In the Projects window right-click the exercise1 entry and choose Clean and Build Project. Then right-click the exercise1 entry again and choose Run Project. The program displays its window, shown below.

   

3. The Seconds Before Notification should be set to 30.
4. Click the Start! button. Notice that it does not redraw correctly.
5. Click the Exit button. Notice that it does not respond at all.
6. Obstruct the view of the window by putting another window on top of part of it. When you move the other window away, notice that the sample application does not redraw its window correctly. An example is shown below.

   

7. After the thirty seconds eventually pass, the message box will be displayed, as shown below. Click the OK button on the message box.

   

8. The application window will begin to respond again. Click its Exit button to shut it down.
9. Choose Profile > Profile Main Project.
10. If a dialog box is displayed asking for permission to modify the project build script, click OK. An example is shown below.

    

11. The Profile dialog is displayed. Click the large Monitor Application button.
12. The Enable Threads Monitoring checkbox should be checked.
13. Click the Run button. If a dialog is displayed that informs you that the Profiler calibration information must first be collected, click its OK button. An example is shown below.

    

    Choose Profile > Advanced Commands > Run Profiler Calibration. The Profiler will display a dialog when calibration is complete; click its OK button. An example is shown below.

    

    To begin profiling, return to step 9, above.

14. The application starts and the IDE displays a Profiler Control Panel, as shown below.

    

15. The Profiler will display thread state in its main window; an example is below.

    

Color coding is used to display thread state.

• Green: the thread is either running or is ready to run.
• Purple: the thread is sleeping in Thread.sleep().
• Yellow: the thread is waiting in a call to Object.wait().
• Red: the thread is blocked while trying to enter a synchronized block or method.

16. Locate the sample Swing application's window (the NetBeans IDE window might be on top of it). Click the Start! button on the sample application and watch what happens to the thread labeled AWT-EventQueue-0. It will turn green and stay that way for a full thirty seconds, as shown in the sample below.

    

    This graph shows why the application is not responding. The thread labeled AWT-EventQueue-0 is the Event Dispatch Thread (EDT) used by Swing to process window events. In a well behaved Swing application, the EDT spends most of its time waiting and very little time running; it should only run for the brief amount of time required to dispatch an event. If the event handlers in the application do not return quickly, however, then the program will become unresponsive, just like in this example.

17. After the thirty seconds pass, the application's message box will be displayed. Locate that message box (the NetBeans IDE window might be on top of it) and click its OK button. Then click the sample application's Exit button to shut it down.
18. The Projects window shares space with the Profiler Control Panel; click the Projects tab to display the Projects window.
19. In the Projects window expand the exercise1 entry by double-clicking it and then expand the Source Packages and profilingthreads entries. Right click the DisplayForm.java entry and select Open.
20. In the Editor window that contains DisplayForm.java, uncomment the block of code that begins at line 132 and ends at line 157. Tip: If the editor is not configured to display line numbers, select View > Show Line Numbers.
21. In the Editor window that contains DisplayForm.java, remove (or comment out) the block of code that begins at line 120 and ends at line 128. It is shown highlighted in the illustration below.

    

22. Choose File > Save. You have just removed the code that was using the EDT improperly and replaced it with a more robust solution. The application should now be much more responsive.
23. Choose Build > Build Main Project (or press F11).
24. Choose Profile > Profile Main Project.
25. The Profile dialog is displayed. Click the large Monitor Application button.
26. Make sure that Enable Threads Monitoring is checked.
27. Click the Run button.
28. When the sample program displays, click the Start! button. Notice how the Profiler's threads graph looks different this time; an example is below.

    

    The EDT is yellow and the thread created by the application, which is named "Our SwingWorker #1" is green. The EDT is not being used to do a time consuming task and as a result the buttons and other program controls remain responsive.

29. Click the Exit button on the sample program.
30. Right click the AWT-EventQueue-0 thread in the Profiler graph and then select Thread Details. The Profiler displays a pie chart showing time spent in each state; an example is below.

    

    This graph can help you determine if your program is spending the correct amount of time in each thread. The example shown is from after the code was repaired so it shows that the EDT spent most of its time waiting, which is exactly the behavior it should have.

31. In the Projects window right-click the exercise1 entry and then choose Close Project.

Summary:

In this exercise you learned how to use the Profiler to start an application and how to interpret the Profiler's thread information graphs in order to track down a performance problem in a Swing application.

return to the top

Background Information:

CPU performance problems are usually associated with specific features in an application. For example, in a reporting system one report might run more slowly than the others. Profiling just the portion of an application that is experiencing performance problems can dramatically reduce the overhead imposed by the profiler. In this exercise you will use the NetBeans Profiler to examine CPU usage in a web application. This sample web application is also used in exercise 3 to show how the Profiler can be used to find memory leaks.

Steps to follow:

1. Choose File > Open Project. Navigate to the <tutorial_root>/netbeansprofiler/exercises folder. Select the exercise2 folder and make sure Open As Main Project is checked. Click the Open Project Folder button.
2. In the Projects window, click the exercise2 entry and choose Build > Clean and Build Main Project from the menu.
3. Then choose Profile > Profile Main Project from the menu. If a dialog box is displayed asking for permission to modify the project build script, click OK.
4. The Select Profiling Task dialog is displayed.
5. Click the Analyze Performance button.
6. Select the Part of Application radio button. Then click the Select button that is next to the Part of Application radio button. The Specify Root Methods window appears.

NOTE: The next three steps are for Milestone 8 only.

7. In the Specify Root Methods window, click the Add button to add a root method to profile. The Select Method window appears.
8. In the Select Methods window, click the Select button. The Profiler displays the Go To Class window.
9. Enter Per into the Class Name text field. Wait for the IDE to show you the list of suitable classes. Select the Performance class. Click the Open button to open its list of methods.

   NOTE: The next two steps are for Profiler v5.0.

10. In the Specify Root Methods window, click the Add From Project... button to add a root method to profile. The Select Methods window appears.
11. In the Class Name text field, type demo.Performance and then press Enter.

    

12. Select the processRequest method by clicking on it in the list of Root Methods and then click the OK button. You have just selected demo.Performance.processRequest as the root method for performance analysis. This means that the demo.Performance.processRequest method and all methods that it calls, and all methods that they in turn call (and so on) will be profiled. Starting from demo.Performance.processRequest, the Profiler does analysis of the method call graph to determine which methods need profiling. Only those methods are profiled - the rest of your application will continue to run at full speed with no profiling overhead.
13. Click the OK button on the Specify Root Methods window.
14. In the Analyze Performance window, select Quick Filter from the Filter list and then click the "..." button next to the Quick Filter entry to specify methods that should not be profiled. The Set Quick Filter window appears. Verify that the Exclusive radio button is selected. Then enter org.apache into the Filter Value text field and click the OK button. All methods in the org.apache package (and child packages) will not be profiled - even if they are called from the root method that was selected. This reduces profiling overhead and filters out information that is not relevant.

    

15. In the Select Profiling Task window, click the Run button. If a dialog is displayed that asks for calibration information, click its OK button; after the Profiler displays a dialog indicating calibration is complete, click that dialog's OK button.
16. The IDE will start Tomcat and display the web application's index.jsp page in a web browser window. At the same time, the Profiler will run in the background. Note: By default, the index.jsp page will be displayed in the browser window that has focus; you might want to open a separate browser window so that you can read these instructions while running the web application.
17. Since you have chosen demo.Performance.processRequest as a root method, you need to use the portion of the web application that causes that root method to run: In your web browser, click Performance Problems to go to the Performance demo page. On the Performance demo page, enter 123456 in the input text field. The optimized option should not be checked. Click the Submit Query button to calculate the largest prime number that is less than or equal to 123456.
18. It will take a couple of seconds before the response appears because the algorithm used for calculating the largest prime number has some performance problems. Also, the Profiler imposes some overhead when monitoring the performance of the processRequest method.
19. After the result 123449 displays in your browser, click the button or choose Profile > Take Snapshot of Collected Results. Click the Combined tab at the bottom of the CPU usage snapshot. The Profiler displays the latest performance results, as illustrated below.

    

    The top window shows the complete method call graph beginning with the root method. The bottom window is a flatter depiction; it shows the Hot Spots in the application - those methods that took the most time to execute.

20. To examine and interpret the results, notice that the processRequest method ran for a total of 4308 milliseconds (ms). Note, however, that very little time was spent running the instructions of the processRequest method itself - the "self time" for processRequest is only 10.1 ms. The vast majority of the time was spent in methods called by processRequest. The Hot Spots displayed in the bottom window are sorted by "self time." By looking at that list you can see that the calculate method took up 97.8% of the execution time. This is not surprising given the amount of work the calculate method has been given to do.
21. To help you decide how your application can be optimized, the NetBeans Profiler helps you identify bottlenecks in your code that were not expected or that will prevent your application from scaling well. Click the calculate entry in the hot spot list to investigate exactly where the time went; this will update the call graph window so that calculate is shown. Since the calculate method does not call any other methods, right-click the calculate entry and choose Go To Source so that you can examine the source code. You will discover it uses a very inefficient algorithm that should be redesigned.
22. Choose Profile > Reset Collected Results to clear the Profiler's buffer. To compare calculate's runtime to an optimized algorithm calculate2, check the optimized option over in the web browser before clicking Submit Query. Wait for the result, then choose Profile > Take Snapshot of Collected Results again. Notice that the processRequest method ran for only 107ms and the calculate2 method took up less than 10% of the execution time!

    

23. Note: The next exercise will pick up where this one left off, so do not close any windows.

Summary:

In this exercise you learned how to have the Profiler do performance analysis on a method.

return to the top

Steps to follow:

1. This exercise picks up where Exercise 2 left off, so be sure to follow the steps in Exercise 2.
2. Choose Profile > Profile Main Project from the menu. If you see a dialog asking whether you want to stop the current profiler process to start a new one as illustrated below, click the Yes button to proceed.

   

   The Select Profiling Task dialog is displayed.

3. In the Select Profiling Task dialog, click the large Monitor Application button.
4. Click the Run button. The IDE displays a Profiler console on the left. Click the button or choose Profile > View > Telemetry Overview. The NetBeans Profiler displays three graphs in the output window at the bottom, as illustrated below.

   

   In the graph on the left the red shading indicates the allocated size of the JVM heap. The purple overlay indicates the amount of heap space actually in use. In the example above the allocated heap size at the last update was over 20 megabytes. Of that a little over 10 megabytes is actually being used to hold Java objects.

   The graph on the right shows the count of active threads in the JVM.

   The graph in the center shows two important heap statistics.

   • The blue line is the percentage of execution time spent by the JVM doing garbage collection and is graphed against the y-axis on the right edge of the graph. Time spent by the JVM doing garbage collection is time that is not available for it to run your application. So if the blue line indicates a large percentage you may want to consider tuning the JVM by configuring a larger heap size (refer to the -Xmx parameter documentation) or perhaps switching to a different garbage collection algorithm.
   • The red line is surviving generations and is graphed against the y-axis scale on the left edge of the graph. The count of surviving generations is the number of different ages of all the Java objects on the JVM's heap, where "age" is defined as the number of garbage collections that an object has survived. When the value for surviving generations is low it indicates that most of the objects on the heap have been around about the same amount of time. If, however, the value for surviving generations is increasing at a high rate over time then it indicates your application is allocating new objects while maintaining references to many of the older objects it already allocated. If those older objects are in fact no longer needed then your application is wasting (or "leaking") memory.

5. The Profiler can do detailed analysis (also referred to as instrumentation) of CPU performance or memory usage, but it cannot do both at the same time. To find out detailed information about the allocation and garbage collection of objects on the JVM's heap you will modify the Profiler's settings. Click the button or choose Profile > Modify Profiling.
6. Click the Analyze Memory Usage button.
7. Select the Record both object creation and garbage collection radio button.
8. Check the Record Stack Trace for Allocations check box.
9. Click the OK button.
10. Now that you have chosen to analyze memory usage you need to use the application in order to determine whether it is using memory efficiently. Click Memory Leak to go to the MemoryLeak demo page.
11. On the MemoryLeak demo page, click Start Leaking.
12. Notice the spike in the Surviving Generations graph, as shown in the example below. This indicates a possible memory leak.

    

13. Choose Profile > View > Live Results. The Profiler will display a dynamic view of the objects allocated in the JVM heap. By default it is sorted by the number of bytes used by all instances of each class. Since a memory leak is suspected, click the Generations column to sort the display by the number of different object ages for each class. An example of the resulting display is shown below.

    

    The columns provide object allocation and memory usage information.

    • Allocated Objects is the number of objects that the Profiler is monitoring. In this example, there are 38 instances of float[] that are being monitored. By default this number will be approximately ten percent of the objects actually allocated by your application. By monitoring only a subset of the created objects the Profiler is able to dramatically reduce the overhead it places on the JVM, which then allows your application to run at close to full speed.
    • Live Objects is the number of the Allocated Objects that are still on the JVM's heap and are therefore taking up memory.
    • The two Live Bytes columns show the amount of heap memory being used by the Live Objects. One column displays a graph, the other displays text.
    • The Avg. Age value is calculated using the Live Objects. The age of each object is the number of garbage collections that it has survived. The sum of the ages divided by the number of Live Objects is the Avg. Age.
    • The Generations value is calculated using the Live Objects. As with Avg. Age, the age of an object is the number of garbage collections it has survived. The Generations value is the number of different ages for the Live Objects.

14. As the program continues to run, the Profiler will update the display. Keep your eye on the entries for float[] and double[]. Notice how their generation values continue to increase. As a result, float[] and double[] continue to move higher in the list. Eventually they will be displayed at the top of the list, right under java.util.HashMap$Entry, which also has an increasing value for generations. As the application continues to run the generations value continues to increase for java.util.HashMap$Entry, float[], and double[], but not for any of the other classes. An example is shown below.

    
    

15. To find out what is causing the generation values to keep increasing, choose Profile > Take Snapshot of Collected Results. Sort the resulting display by Generations. Right-click the entry for double[] and then choose Show Allocation Stack Traces. The Profiler displays all the methods that have allocated one or more double[] objects. An example is shown below.

    

    Note that of the methods that have allocated double[] objects, only one method has created double[] objects that have a high generation value. That method is run(), in the aptly named demo.memoryleak.LeakThread class.

16. Right-click the entry for the run() method and choose Go To Source... The Profiler displays the source code, as shown below.

    Note that double[] and float[] objects are being allocated and then placed into a HashMap. They are never removed, however, which means the references held by the HashMap prevent the JVM from ever garbage collecting those objects. This is a pretty typical Java memory leak: objects are placed into a Map and then forgotten. Since the Map used in this example is a HashMap, the associated java.util.HashMap$Entry objects are also leaking.

17. End the profiling session by choosing Profile > Stop or click the button.
18. In the Projects window, select the exercise2 entry and then choose File > Close Project from the menu.

Summary:

In this exercise you learned how to use the Profiler to monitor the creation of objects by an application. You saw the types of indications given by the Profiler when an application has a memory leak.

return to the top