The JVM ships with some alternate JIT compilation algorithms. The current default al-
gorithm was, at one time, somewhat experimental, but this is now the recommended
Disabling young GCs before full GCs
Setting ScavengeBeforeFullGC to false means that when a full GC occurs, the JVM
will not perform a young GC before a full GC. That is usually a bad thing, since it means
that garbage objects in the young generation (which are eligible for collection) can pre-
vent objects in the old generation from being collected. Clearly there is (or was) a point
in time when that setting made sense (at least for certain benchmarks), but the general re-
commendation is not to change that flag.
Binding GC threads to CPUs
Setting the last flag in that list means that each parallel GC thread is bound to a particular
CPU (using OS-specific calls). In limited circumstances—when the GC threads are the
only thing running on the machine, and heaps are very large—that makes sense. In the
general case, it is better if GC threads can run on any available CPU.
As with all tunings, your mileage may vary, and if you carefully test the AggressiveHeap
flag and find that it improves performance, then by all means use it. Just be aware of what it
is doing behind the scenes, and realize that whenever the JVM is upgraded, the relative bene-
fit of this flag will need to be reevaluated.
1. The AggressiveHeap flag is a legacy attempt to set a number of heap parameters
to values that make sense for a single JVM running on a very large machine.
2. Values set by this flag are not adjusted as JVM technology improves, so its useful-
ness in the long run is dubious (even though it still is often used).