code pro pro filer tutorial

8/3/2019 Code Pro Pro Filer Tutorial

1/27

CodePro Profiler Tutorial

Table of Contents

Discovering Performance Bottlenecks .................................................................................................... 2Profiled Application ................................................................................................................. 2Discovering Performance Bottlenecks .................................................................................... 2

Memory Optimization .............................................................................................................................. 4Profiled Application ................................................................................................................. 4Memory Optimization .............................................................................................................. 4

Memory Optimization Using Allocation Tracking and Object Lifetime Profiling .................................... 8Profiled Application ................................................................................................................. 8Memory Optimization .............................................................................................................. 8

Discovering Memory Leaks ................................................................................................................... 12Profiled Application ................................................................................................................12Discovering Memory Leaks................................................................................................... 12Finding Memory Leak Candidates ........................................................................................ 15

Deadlock Detection ............................................................................................................................... 19Profiled Application ............................................................................................................... 19Detecting Deadlocks ............................................................................................................. 19

Profiling J2EE Applications ................................................................................................................... 21

Profiled Application ............................................................................................................... 21

Prerequisites ......................................................................................................................... 21

Profiling J2EE Application ..................................................................................................... 21


2/27

COPYRIGHT 2007 INSTANTIATIONS, INC. ALL RIGHTS RESERVED.

PAGE 2

CodePro Profiler

Discovering Performance Bott lenecks

Profiled Applicat ion

Profiled application: PointEvaluator

Project: com.instantiations.sample.bottleneck

Description:

The application generates 100,000 points in a three-dimensional space in a random manner (allcoordinates ranging between 0.0 and 1.0). Each point has a mass associated with it. The center of

mass is computed and all points distant from the center of mass by less than 0.5 are removed from theset. The execution time of the application is shown in the console after finishing.

Each point is represented as an instance of the class Point. During the processing, the points are

stored in an ArrayList.

Discovering Performanc e Bott lenecks

1. Launch the application in profile mode. Choose CPU sampling.

2. Wait until the application finishes.

3. Estimate the execution time of the application by looking in the Console.

The execution time is more than 44 seconds, which is too much for this application.

4. Take a CPU snapshot and open it.

5. Look at the Hot Spots view. Sort the methods by Self Time.


3/27


PAGE 3

The method that consumed the greatest amount of CPU time is the method remove in the class

java.util.ArrayList. This method is being invoked every time we need to remove a point

because we chose to use an ArrayList to store the collection of points we are working with.

While we cannot change the implementation of remove, we should still try to understand why somuch of the time is being spent in it. There are two possible reasons, both of which are true in

this case. The first reason is the number of times its being invoked. If we assume a randomdistribution of points, then about 50% of them should be getting removed. Thats around 50,000invocations of the remove method.

The second reason is the amount of time spent in remove each time its called. A list is a good

choice of data structure when the number of elements is relatively small or when you dont needto search it, but the remove method needs to search the list to find the index of the element to be

removed every time it is invoked. It does so using a linear search, which is fairly slow when there

are between 100,000 and 50,000 items in the list.

There are two possible solutions. The first is to change the algorithm so that we dont need to

remove points from the list, possibly by creating a second list and adding the points werekeeping to it. The second solution is to use a data structure from which the points can beremoved in less time. Well choose the second solution because it requires fewer changes to theexisting code.

6. Change the type of collection from ArrayList to HashSet (see the comparison of files

PointSystem.java in the projects com.instantiations.sample.bottleneck and

com.instantiations.sample.bottleneck.solved).

7. Profile the changed application.

8. Note that the execution time is less than 1 second, which is much more reasonable.


4/27


PAGE 4

Memory Optimization


Profiled application: ThingsTest

Project: com.instantiations.sample.memory

Description:

The application generates 50,000 instances of the class Thing (things have a name, a value, and a

collection of named properties) and sets the property Broken to true for approximately 5% of the

created things. It doesnt set any properties on the other things.

The type of collection of things is ArrayList.

The type of the field properties is HashMap.

Memor y Optim ization

1. Launch the application in the profile mode.

2. Watch the Memory Telemetry view.

The amount of used heap memory is more than 8 MB, which is too much for this application.

3. Take a memory snapshot and open it.

4. Look at the Biggest Objects view.


5/27


PAGE 5

The biggest object which can interest us is an instance of java.util.ArrayList.

5. Use java.util.ArrayList as a name filter and open the Class List view.

Both the shallow size of class java.util.ArrayList and the number of instances are small

compared to the retained size, which tells us that the list is probably not the problem, itsmore likely the elements stored in the list that are using too much memory. To confirm this,lets look at the problem from a different angle.

6. Select the Class List view and sort the classes by Shallow Size.


6/27


PAGE 6

The class with the biggest shallow size is java.util.HashMap. It is also the class with the

biggest number of instances and one of the largest retained sizes.

The number of instances of the class java.util.HashMap is near 50,000. The number ofobjects of the class java.util.HashMap$Entry is near 2,500. Because there are fewer

entries than there are hash maps, it tells us that most of the hash maps must be empty (at least47,500 of them).

There is another class with almost as many instances: the class Thing.

7. Look at the implementation of the class Thing. We can see two interesting facts. First, every

instance has a field named properties of type HashMap. Second, this field is initialized to an

instance of HashMapwhen the instance of Thing is created. We know from the problem

description that we are only setting the value of a property on about 5% of the instances ofThing.

This suggests that a possible solution would be to leave the field properties un-initialized untilwe first set a property, treating a value of null as being equivalent to any empty HashMap.

8. Change the code to initialize the field property only if a property is set on the thing (see thecomparison of files Thing.java in the projects com.instantiations.sample.memory and

com.instantiations.sample.memory.solved).



11. Look at the Class List view. Use java.util.HashMap as name filter.


7/27


PAGE 7

The number of object of class java.util.HashMap is near 2,500, which is what we would

have expected.

12. Look at the Basic Telemetry section in the Session Explorer.

The amount of used heap memory is now less than 3 MB.


8/27


PAGE 8

Memory Optimization Using Allocat ion Tracking

and Object Lifet ime Profiling




Description:

The application generates 50,000 instances of the class Thing (things have a name, a value, and a

collection of named properties) and sets the property Broken to true for approximately 5% of the

created things. It doesnt set any properties on the other things.

The type of collection of things is ArrayList.

The type of the field properties is HashMap.

Memor y Optim ization

1. Create a profiling launch configuration. Choose BCI profiling without filters. Turn on allocation

tracking and object lifetime profiling. Launch application in profile mode.


The amount of used heap memory is more than 8 MB, which is too much for this application.

3. Take a memory snapshot.

4. Take a CPU snapshot.

5. Stop the profiling session.


9/27


PAGE 9

6. Open the memory snapshot.

7. Open the Class List view and sort classes by Shallow Size to find classes with the biggest

amount of memory allocated to store objects of these classes.

The class with the biggest shallow size is java.util.HashMap. It is also the class with the

biggest number of instances and one of the largest retained sizes.

The number of instances of the class java.util.HashMap is near 50,000. The number of

objects of the class java.util.HashMap$Entry is near 2,500. Because there are fewer

entries than there are hash maps, it tells us that most of the hash maps must be empty (at least47,500 of them).

8. Use java.util.HashMap as a name filter.

9. Look at the Object Lifetime view.

The Allocation hot spot method created by the biggest number of objects ofjava.util.HashMap class is the method

com.instantiations.sample.memory.Thing.. 50,000 objects of

java.util.HashMap class have been created in the constructor of class Thing.

10. Open the CPU snapshot.


10/27


PAGE 10

11. Look at the Allocation Method List view sorted by Own Shallow size.

Methods with the biggest amount of shallow size are java.util.HashMap.,

com.instantiations.sample.memory.Thing. ,

com.instantiations.sample.memory.ThingsTest.main .

12. Look at the Allocation Hot Spots view sorted by Shallow size.

Methods with the biggest amount of shallow size are the same three methods.

13. Open the implementation of the methodcom.instantiations.sample.memory.Thing. .

14. Look at the implementation of the class Thing. The field named properties is initialized to an

instance of HashMapwhen the instance of Thing is created. We know from the problem

description that we are only setting the value of a property on about 5% of the instances of


11/27


PAGE 11

Thing. This suggests that a possible solution would be to leave the field properties un-

initialized until we first set a property, treating a value of null as being equivalent to any emptyHashMap. The Allocation views confirm this.

15. Change the code to initialize the field property only if a property is set on the thing (see thecomparison of files Thing.java in the projects com.instantiations.sample.memory and

com.instantiations.sample.memory.solved).


17. Look at the Memory Telemetry view.

The amount of used heap memory is now less than 3 MB.


19. Look at the Class List view. Use java.util.HashMap as name filter.

The number of objects of the class java.util.HashMap is close to 2,500, which is what we

would have expected.


12/27


PAGE 12

Discovering Memory Leaks




Description:

The application generates a number of instances of the class Thing (things have a name, a value,

and a collection of named properties, and two things are defined to be equal if they have the samename). It sets the name of each thing where the name is the concatenation of the string Thing anda random number (0 - 999). The property Broken is set to true for approximately 5% of the created

things. It doesnt set any properties on the other things.

The created things are used as keys in a HashMap that maps things to their names. The

expectation is that there will never be more than 1,000 things in the map at any given time becausethat is the number of possible names.

The type of the field properties is also HashMap.

Discovering Memory Leak s

1. Launch the application in the profile mode.


Used heap memory constantly increases. It possibly means there's a memory leak.

3. Force a garbage collection.


13/27


PAGE 13

This action hasnt affected the memory usage increase so the problem isnt uncollectedgarbage.


5. Take a second memory snapshot after some period of time.

6. Open the second memory snapshot.

7. Look at the Biggest Objects view.

The biggest object is an instance of the class java.util.HashMap.

8. Look at the Class List view. Use java.util.HashMap as a name filter.

The number of instances of this class is near 33,000. Thats too high because only 1,000 differentnames for things are possible and only 5% of them can have a property. So the number of

objects should be near 1,000.

9. Open the first memory snapshot.


14/27


PAGE 14

10. Compare these snapshots.

The retained size of the class java.util.HashMap in the first snapshot (7,283,840) is much

less than the retained size in the second snapshot (11,642,080). This indicates that at least one

of the hash maps is probably growing without bounds, which is a common symptom of a memoryleak.

The most likely candidate is the hash map mapping instances of Thing to their names. This mapcould only be growing without bounds if two instances of the class Thing that have the same

name are not comparing as equal.

11. Checking the class Thing, the problem quickly becomes apparent: the method equals was not

implemented, so they are defaulting to using object identity.

12. Add the method equals (and hashCode, of course) to the class Thing (see the comparison of

files Thing.java in the projects com.instantiations.sample.memory.leaks and

com.instantiations.sample.memory.leaks.solved).



15. Look at the Class List view. Use java.util.HashMap as a name filter.

The number of instances of the class java.util.HashMap is near 1,000, which is what we

expected.

16. Check the Memory Telemetry view to verify that the amount of memory being consumed is

holding steady.


15/27


PAGE 15

Finding Memor y Leak Candidates

1. Create a Profile launch configuration. Choose BCI profiling mode and enable Track objectallocations and Collect object lifetime information and clear the BCI filters. Launch the

application in the profile mode.


Used heap memory constantly increases. It possibly means there's a memory leak.

3. Force a garbage collection.

This action hasnt affected the memory usage increase so the problem isnt uncollectedgarbage.

4. Take a memory snapshot and stop the profiler.

5. Open the Memory Leak Candidates view.

6. Start Memory Leak Candidates discovering.


16/27


PAGE 16

The first found candidates with the biggest retained size are instances of the classjava.util.HashMap$Entry.

7. Stop Memory Leak Candidates discovering.

8. Find path from GC root to the object java.util.HashMap$Entry.

GC root for the object java.util.HashMap$Entry is java.util.HashMap.

9. Look at the Object Lifetime view. Use java.util.HashMap as a name filter.

The number of instances of this class is near 25,000. Thats too high because only 1,000 different

names for things are possible and only 5% of them can have a property. So the number ofobjects should be near 1,000. Besides it the average GC count for this objects is 7.


17/27


PAGE 17

10. Look at the Summary view of this snapshot.

Total GC count is 15. So the average GC count for objects of class java.util.HashMap is a

half of total GC count.

11. Go back to the Object Lifetime view.

Look at the allocation hot spots for the class java.util.HashMap. The constructor of class

Thing has created the most of instances of the class java.util.HashMap and the lifetime of

these instances is rather long. The hash map mapping instances of Thing to their names couldonly be growing without bounds if two instances of the class Thing that have the same name

are not compared as equal.

12. Checking the class Thing, the problem quickly becomes apparent: the method equals was not

implemented, so they are defaulting to using object identity.

13. Add the method equals (and hashCode, of course) to the class Thing (see the comparison of

files Thing.java in the projects com.instantiations.sample.memory.leaks and

com.instantiations.sample.memory.leaks.solved).


15. Take a Memory snapshot.

16. Open the snapshot and look at the Object Lifetime view. Use java.util.HashMap as a namefilter.

The number of instances of the class java.util.HashMap is near 1,000, which is what we

expected.


18/27


PAGE 18

17. Check the Memory Telemetry view to verify that the amount of memory being consumed isholding steady.

18. Stop the profiler.


19/27


PAGE 19

Deadlock Detection


Profiled application: Smorgasbord

Project: com.instantiations.sample.deadlocks

Description:

This application implements a system of work of a smorgasbord. The menu consists of only soup. A

guest should use a ladle and a spoon to eat the soup. Two guests came to the smorgasbord. While thefirst guest tries to eat his soup, the second one looks around.

Detec ting Deadlocks

1. Create a Profiler launch configuration with the thread profiling enabled and launch the applicationin profile mode.

2. Watch the console view. Notice that first guest hasnt said Lunch is over. That means that hehasnt eaten. Its possible that there is a deadlock in the application.

3. Open the Deadlocks view.

One deadlock has been found. Threads First Guest andSecond Guest have blocked eachother.


20/27


PAGE 20

4. Open the Current Monitor Usage view.

The first class of with blocked event type is Smorgasbord$Ladle and the class with blocked

event type is Smorgasbord$Spoon. The first guest has taken a ladle from the table and the

second guest took his spoon. So the first guest cant finish his lunch.

5. Change the first synchronized block (ladle) for the first guest so that it closes before opening thesecond synchronized block (spoon). See the comparison of files Smorgasbord.java in the

projects com.instantiations.sample.deadlocks and com.instantiations.sample.deadlocks.solved.


7. Watch the console view. The first guest has finished his lunch because the second guest couldnttake his spoon.


21/27


PAGE 21

Profiling J2EE Applications


Profiled J2EE application: DemoServlet

J2EE server: Apache Tomcat v5.5

Project: com.instantiations.sample.j2ee

Prerequisites

1. Eclipse WTP to be installed.

2. Any supported J2EE server.

3. Start Eclipse.

For this demo we use WTP version 2.0 and Apache Tomcat v5.5 server.

Profiling J2EE Application

9. Open Servers view in the Java EE perspective.

10. Add new Apache Tomcat v5.5 server.


22/27


PAGE 22

11. Import J2EE application com.instantiations.profiler.j2ee.


23/27


PAGE 23

12. Profile the application using Profile With CodePro As item in the context menu.


24/27


PAGE 24

Select Tomcat v5.5 Server in the list.

Profiling perspective opens after profiling has been started.

13. Take CPU snapshot after request served.

14. Open Method List view.

There are com.instantiations.sample.j2ee.DemoServlet methods in the list. Thats mean that

J2EE application has been profiled.


25/27


PAGE 25

15. Lets consider another way to profile J2EE application.

Start profiling of Apache Tomcat server.

Select CodePro Profiler launcher in the list.

16. Open web browser.


26/27


PAGE 26

17. Run target J2EE application via browser (use linkhttp://localhost:8080/com.instantiations.sample.j2ee/DemoServlet).

18. Go to Eclipse window. Target application has been profiled on server.

19. Lets consider managing of profile mode launch configuration.

Use Open Profile Dialog item in the profiling menu.


27/27

code pro pro filer tutorial

Documents