This article has been updated to include the GC Portal software for Linux and Java Desktop System (JDS), available both for Sun Java System Application Server 7 (formerly Sun ONE Application Server 7 (S1AS7)) and Tomcat servers. Originally, it was made available only for Solaris and Windows. This version of the GC Portal software also includes VisualGC integrated within the GC Portal.
The GC Portal enables analysis and performance tuning of Java applications from a garbage collection (GC) perspective by mining the
verbose:gc logs generated by the JVM. GC Portal is a one-stop page for GC issues and includes an extensive collection of whitepapers, case studies and other material. The Portal is intended to be used with HotSpot JVM from Sun Microsystems, distributed as part of Java 2, Standard Edition (J2SE). Use of the GC Portal enables developers to model application and JVM behaviors from a GC perspective. This article introduces the design and features of the GC Portal, to enable developers to use it as a tool for analyzing and tuning GC.
The GC Portal requires the use of the following switches by the JVM for the generation of
verbose:gc logs which are processed by the Portal for analysis.
-verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails
Other JVM switches are not required to be used for generating the appropriate logs for GC Portal, but can be added as considered appropriate for tuning and sizing the JVM and the application.
Note: -XX switches are non-standard and are also subject to change without notice in future JVM releases.
Modeling Java applications makes it possible for developers to remove unpredictability attributed to the frequency and duration of pauses for garbage collection. These pauses are directly related to:
Based on the analysis provided by the GC Portal for a specific set of
verbose:gc log files fed to the Portal, developers can build a model which helps them understand the application and JVM behavior better.
verbose:gc logs contain valuable information about:
The behavior of the application can be charted and analyzed to determine the different relationships between pause duration, frequency of pauses, object creation rate, and memory freed. Analysis of this information can enable developers to tune an application's performance, optimizing GC frequency and collection times by specifying the best heap sizes, other JVM options, and alternate GC algorithms for a given situation.
This kind of information can be used to performance tune the process of garbage collection.
Average GC pauses in the young and old generation
The average time the application is suspended while garbage collection is done in the JVM.
Average GC frequency in the young and old generation
The periodicity at which the garbage collector runs in the young and the old generation. This can be obtained since the time instance of each GC activity is logged.
GC sequential overhead
The percentage of system time for which the application is suspended for garbage collection to take place. Calculated as Avg. GC pause * Avg. GC frequency * 100%
GC concurrent overhead
The percentage of system time for which garbage collection happens concurrently with the application. Calculated as Avg. concurrent GC time (sweeping phase) * Avg. concurrent GC frequency / no. of CPUs
Memory recycled by each GC in the young and old generation
The total garbage collected during each GC.
The rate at which data gets allocated by the application in the young generation. If young generation heap occupancy_at_start_of_current_gc=x, occupancy_at_end_of_previous_gc = y and the GC frequency is 1 per second, then the allocation rate is approximately x-y per second.
The rate at which data gets promoted to the old generation.
Total data allocated by the application
This is the total data which is allocated by the application per transaction.
Total data can be split into short term data and long term data
Long term data is what survives the young generation GC cycles and is promoted to the old generation.
Short term data
The short lived data that dies very quickly and is collected in the young generation. This can be calculated as Total Data - Long Term Data.
Total active data
This is the total data alive at any instance of time. This is critical for building a model for sizing the JVM heap. For example, for a load of 100 transactions per second, with long term data of 50K per transaction lasting for a minimum of 40 seconds, the minimum memory footprint of the old generation would have to be
50K*40s*100 = 200M
These can be detected and "out of memory" errors can be better understood by monitoring the garbage collected at each sweep as shown by these logs.
There is a lot of useful GC-related information which the JVM can log into a file. This information is used by the GC Portal to tune and size applications and the JVM from a GC perspective. Logs containing detailed GC information are generated when a Java application is run with the following switches:
This flag turns on the logging of GC information. Available in all JVMs.
Prints the times at which the GCs happen relative to the start of the application. Available only from J2SE1.4.0.
Gives details about the GCs, such as:
Available only from JVM1.4.0.
The GC Portal can be used to better understand an Application's GC behavior so as to performance tune and size applications to run optimally under lean, peak, and burst conditions. It supports J2SE1.2.2, J2SE1.3, J2SE1.4 and J2SE1.4.1 onwards, including the two new garbage collection implementations, the Parallel Collector and the Concurrent Collector. It allows developers to submit GC log files and analyze application behavior, based on these log files. It also considers some application- and environment-specific information including:
verbose:gclog format is not standard, and there have been changes from the JVM, this information is needed by the GC Portal.
The GC Portal is comprised of four engines:
verbose:gclog files, mines them and reports:
-XX:+PrintTenuringDistributionswitch is used to generate logs.
Figure 1 is a snapshot of an example report presented by the Analyzer engine of the GC Portal.
Figure 1. Snapshot of the Analysis Engine from the GC Portal
(Click image to enlarge.)
Most of the information that is presented by the Analyzer engine in tabular form can be plotted graphically. Multiple charts can be plotted on the same graph to aid comparisons.
Figure 2. Snapshot of the Graphical Engine of the GC Portal
(Click image to enlarge.)
The Intelligence Engine is comprised of:
verbose:gclogs. The user can choose the files (amongst all those were loaded) for modeling based on the following choices:
Figure 3. Snapshot of the Intelligence engine of the GC Portal
(Click image to enlarge.)
Session and Storage Engine
Figure 4. Snapshot of the Storage Engine of the GC Portal
(Click image to enlarge.)
The visualgc tool attaches itself to an instrumented HotSpot JVM and collects and graphically displays garbage collection, class loader, and HotSpot compiler performance data. It is incorporated into the GC Portal for gathering GC-related information at JVM runtime. GC Portal uses the webstart tool for running and displaying the visualGC information in a browser. More details on this tool are available at the CoolStuff - jvmstatpage. The ReadMe file for running VisualGC from within the GC Portal is built into the GC Portal Software.
Read the ReadMe section to download, configure and run the GC Portal software.
The author would like to thank Mayank Srivastava, Nagendra Nagarajayya, Nandula Narasimham and S.R.Venkatramanan for their contribution to the GC Portal. The author would also like to thank the Sun JVM garbage collection architects and experts John Coomes, David Detlefs, Steve Heller, Peter Kessler, Ross Knippel, Jon Masamitsu, James Mcilree and Y.S. Ramakrishna for their help and guidance on this work. The author would also like to thank the members of Sun's JVM performance team, Timothy Cramer and Brian Doherty (author of VisualGC and jvmstat tools) for their help towards integrating VisualGC into GC Portal.
Alka Gupta is a Member of the Technical Staff at Sun Microsystems. She's responsible for working with Sun's ISV's and partners to help them adopt the emerging Sun technologies and platforms quickly and efficiently. She has been working in the area of performance tuning on Sun platforms for almost 7 years, and has been in this industry for nearly 10 years. Alka graduated from the Indian Institute of Technology (IIT), India.