Malpractice: Permanently using -Xdisableexplicitgc or -XX:+DisableExplicitGC
kgibm 0600027VAP Comment (1) Visits (7812)
It is generally a malpractice for an application to call System.gc() or Runtime.gc() (hereafter referring to both as System.gc(), since the former simply calls the latter). By default, these calls instruct the JVM to perform a full garbage collection, including tenured spaces and a full compaction. These calls may be unnecessary and may increase the proportion of time spent in garbage collection than otherwise would have occurred if the garbage collector was left alone.
The generic JVM arguments -Xdisableexplicitgc (IBM) and -XX:
However, there are potential unintended consequences: For example, in some JVM implementations, core Java functionality such as DirectByteBuffer cleanup may be affected in some situations, leading to unnecessary OutOfMemoryErrors and crashes since the self-healing calls to System.gc to cleanup iceberg native objects have no effect.
Therefore, it is a malpractice to use -Xdisableexplicitgc or -XX:
Method #1: IBM JVM only - Use -Xtrace trigger
Restart the JVM with the generic JVM argument -Xtr
Any time System.gc is called, a stack trace will be printed to native_stderr.log. For example:
Important Note: Until IBM Java 7.1, using -Xtrace may have a significant performance overhead because the JIT behavior is impacted for all methods. Before using this option in production, test its impact in a test environment.
Method #2: Use a tracing profiler
There are many tracing profilers which can time method calls. Find a profiler with the option of only profiling the Runtime.gc method and with the option of getting a call stack to the profile samples.
Method #3: Attach a debugger
Attach a debugger and set a breakpoint in the Runtime.gc method. Then inspect the call stack.