In a previous entry entitled "What's calling System.gc()?" Ian talked about how to find out what code is calling System.gc() using method trace and the jstacktrace or javadump options.
For users of "IBM Monitoring and Diagnostic Tools for Java - HealthCenter" (Health Center) there's a much simpler mechanism, which I'll cover below.
Detecting the (over) use of System.gc() using Health Center
Health Center provides live monitoring and analysis of a number of areas of a running JVM and application, including Garbage collection (GC). Part of the GC analysis determines if calls to System.gc() are being made, and the rate at which those calls are occurring. If the rate is high, Health Center will flag up a warning or an error in the Status panel:
In this case Health Center has highlighted a warning that calls to System.gc() are accounting for 15% of the GC cycles.
If your worried about any calls to System.gc(), clicking on the "Garbage Collection" link will give you a more detailed view of GC, including a count of the number of calls to System.gc() (forced GCs), the number of allocation failures (non-forced GCs) and the total number of GC cycles.
Determining what is calling System.gc()
If you want to know what code is making the calls to System.gc(), the "Profiling" link contains the information. Clicking on the link opens the following panel:
This gives a breakdown of the various methods that are being called in the application. If you then filter on "System.gc()", and click on the "Invocation paths" tab in the bottom window, you see the call stack for the calls to System.gc():
In this case, there is only one method calling System.gc(), which is StoreData.run(). If there were multiple methods calling System.gc() then there would be an expandable tree under the System.gc() call, and the percentage against each displayed method would show the rate at which each method is responsible for calling System.gc(). In the case above there is only one caller, it is therefore responsible for 100% of the calls to System.gc().