Malpractice: Permanently using -Xdisableexplicitgc or -XX:+DisableExplicitGC
kgibm 0600027VAP Comments (2) Visits (14282)
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 or -Xdump
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
If you are on IBM Java >=6 and < 7.1, then you may instead use -Xdu
This will print a stack trace to stderr every time a full garbage collection occurs:
Thread=WebContainer : 263509055 (F6C04688) Status=Running at java
However, it will also print a stack any time a full GC occurs for non-explicit reasons. You can simply look for any stacks that begin with Runtime.gc to figure out which ones are explicit.
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.