Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
HPjmeter Version 3.1 User's Guide > Chapter 8 Using Visualizer Functions

Using Specialized Garbage Collection Displays

» 

Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Glossary

 » Index

GC data displays are available immediately on opening a .vgc file that was generated by running your application with -Xverbosegc or -Xloggc options. This data is presented in the following visualizers:

See also:

For an explanation of Java memory terminology, see the Sun Developer Network publication Memory Management in the Java HotSpot™ Virtual Machine (.pdf)

Allocation Site Statistics

This visualizer displays the sites (methods) in the JDK and user Java code where objects have been created. The display includes the number of objects created at each site (Invoke Count), the average size of each object, and the amount of memory occupied by the objects. This metric is useful when you choose to decrease heap pressure by modifying the application code.

Requires use of -XX:+PrintAllocStatistics in the run command:

See “Collecting Allocation Site Statistics for Viewing in HPjmeter” for an example of command syntax.

Allocation sites can originate from interpreted as well as compiled Java code. When specifying –XX:+PrintAllocStatistics, only allocations from compiled code are reported. However, because the Java Virtual Machine detects and compiles the most active Java methods as early as possible, the most active allocation sites (the sites most likely to cause GC performance problems) are reported.

Figure 8-19 GC Metric: Allocation Site Statistics

Visualizer showing allocation site
statistics.

The default sort on this table is determined by % Allocated, meaning the percent of memory allocated to the objects generated by the compiled portion of the running Java application. The values in this column are displayed in descending order, from greatest area of memory use to the least. Making code changes first in the area where memory use is greatest can have more significant impact on the heap.

Heap Usage After GC

This visualizer shows heap usage in the eden space and in the old, survivor, and permanent generations after each garbage collection. When viewed with consideration of the type of each event, this graph provides a general picture of the heap resources minimally required by an application.

NOTE:

Difference in Display of Garbage Collection in the Heap Monitor and the Heap Usage After GC Visualizer  Monitoring visualizers like the Heap Monitor show only object data from the eden, survivor, and old generation spaces. Visualizers that display verbosegc data, like the Heap Usage After GC visualizer, show object data from the permanent generation, as well as from the eden, survivor, and old generation spaces.

Figure 8-20 GC Metric: Heap Usage After GC

Visualizer showing heap usage after
GC over time, with scavenges and full GC events distinguished by color
and shape.

Duration (Stop the World)

This visualizer shows the amount of stop-the-world time spent for each garbage collection event.

A well-tuned application shows a relatively large number of short scavenges with less frequent, but more expensive, full garbage collections.

This graph is also useful for exposing the cost of explicit System.gc() method calls within an application, which often result in expensive and unneeded garbage collection overhead.

Figure 8-21 GC Metric: Duration

Visualizer showing stop-the-world
times, with GC events distinguished by color and shape.

Cumulative Allocation

This visualizer shows the cumulative amount of storage for new objects requested by the application over time, which can indicate the overall progress of the application. Because the rate at which an application creates new objects is often an indicator of its performance, changes in the slope of this curve may indicate opportunities for tuning garbage collection.

To see a more dramatic presentation of incremental changes in object creation, see the Creation Rate visualizer.

Note that storage recovered by the garbage collector for unused objects is not deducted from the cumulative amount.

Figure 8-22 GC Metric: Cumulative Allocation

Visualizer showing cumulative storage
requested by application over time, with GC events distinguished by
color and shape.

Creation Rate

This panel shows the incremental object creation rate for the application as observed at each garbage collection event. The increment at each data point is the amount of elapsed time since the previous GC event.

The rate of object creation can be a good measure of your application's overall performance. By correlating GC events with changes in the object creation rate, you can discover opportunities for improving this performance through heap parameter tuning.

Figure 8-23 GC Metric: Creation Rate

Visualizer showing cumulative creation
rate over time, with GC color distinctions off and lines connecting
GC events in the order in which they occurred.

User-Defined X-Y Axes

This visualizer is supplied to help you to experiment with your own combinations of data gathered by -Xverbosegc or -Xloggc that you might find useful.

Select variables for the X and Y axes from the pull-down lists. HPjmeter plots the X-Y relationships for your captured data file. For a partial list of available metrics, see –Xverbosegc and –Xloggc Options and Their Corresponding Metrics.

For some user-defined selections, it is possible that the data capture obtained the GC type without being able to ascertain the numerical value of the data point. Data points with unknown numerical values are shown in gray near zero (0) on the X or Y axis of a graph. To determine the GC type of a data point, check the shape in the legend given below the graph.

Figure 8-24 User-Defined Comparisons of GC Metrics

Visualizer showing X-Y axes controls
to use to create your own metric comparison.

Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© 2005-2008 Hewlett-Packard Development Company, L.P.