Today began the actual combat Java Virtual Machine four: "Disable System.GC ()".
Total of 5 Series
- "Heap overflow processing" in one of the actual Java virtual machines
- Virtual machine working mode for Java Virtual machine
- The three "G1 of the New generation GC" of Java Virtual machine
- Live Java Virtual machine Four "Disable System.GC ()"
- Real-time Java Virtual Machine Five "turn on JIT compilation"
By default, System.GC () explicitly triggers the full GC directly, while recycling the old and new generations. In general, we believe that garbage collection should be automated without the need for manual triggering. If garbage collection is triggered too frequently, there is no benefit to system performance. Therefore, the virtual machine provides a parameter DISABLEEXPLICITGC to control whether the GC is triggered manually.
The implementation of System.GC () is as follows:
Runtime.getruntime (). GC ();
RUNTIME.GC () is a native method that is eventually implemented in Jvm.cpp, as follows:
Jvm_entry_no_env (void, jvm_gc (void)) Jvmwrapper ("jvm_gc"); if (! DISABLEEXPLICITGC) { universe::heap ()->collect (GCCAUSE::_JAVA_LANG_SYSTEM_GC); } Jvm_end
As you can see, if-XX:-+DISABLEEXPLICITGC is set, the conditional judgment cannot be established, then the explicit GC is disabled, so that System.GC () is equivalent to an empty function call.
Excerpt from
Combat Java Virtual Machine Four: Improve performance, disable System.GC ()?