Garbage Collection (GC) logging data is generated by the -verbose:gc command line option. The log information is really useful for monitoring Java applications, and for helping you diagnose performance or memory problems. Often, you want to diagnose a problem when it first happens. To do this, you need to enable logging so that you already have the monitoring information.
The problem with enabling any logging or tracing is that it can affect the overall performance of the system. How do you determine the impact of enabling -verbose:gc on an IBM Java Runtime? How do you decide if the cost of continual logging is too great?
In theory, the performance impact of GC logging should be very low. The data is always generated internally by the garbage collector, because it is used to enable self-tuning. There should be no significant overhead for logging the values. The cost of enabling -verbose:gc should be the same as adding any output markup, then writing the output to either stderr or a log file.
For a running Java application we would expect the GC overhead: (the percentage of time spent running GC versus the time spent running Java code) to be around 3% or less. Some very basic quantitative tests we carried out during development work has shown us that GC logging causes GC to take about 1% longer, and thereby would increase that GC overhead to 3.03%. This shows that the overall performance cost of enabling GC logging is as low as 0.03%.
From this we can see that enabling GC logging has no real performance impact on the application, but gives you the benefit of monitoring for potential performance and memory problems, and helping you to diagnose them the first time they happen.
The other consideration for any logging is making sure that you store the logs for later analysis. This almost always requires disk space. With the -verbose:gc option, you can choose to log the data to a file rather than the default stderr, by using the following command line options:
where the optional <X> and <Y> parameters are the number of files to write to, and the number of garbage collection cycles a file should contain. This allows logging to occur on a circular basis.
So, in summary, it is often a good idea to run your application with -verbose:gc switched on; the performance overhead is very low, and the disk space required by the logging output can be managed using rotating log files.