Java Reference
In-Depth Information
ber of old generation regions that can be collected during a mixed GC will decrease to meet
the pause time goal, which increases the chances of a concurrent mode failure.
If setting a pause time goal does not prevent the full GCs from happening, these various as-
pects can be tuned individually. Tuning the heap sizes for G1 is accomplished in the same
way as for other GC algorithms.
Tuning the G1 background threads
To have G1 win its race, try increasing the number of background marking threads (assuming
there is sufficient CPU available on the machine).
Tuning the G1 threads is similar to tuning the CMS threads: the ParallelGCThreads option
affects the number of threads used for phases when application threads are stopped, and the
ConcGCThreads flag affects the number of threads used for concurrent phases. The default
value for ConcGCThreads is different in G1, however. It is defined as:
ConcGCThreads = (ParallelGCThreads + 2) / 4
The arithmetic here is still integer-based; G1 simply increases that value one step later than
CMS.
Tuning G1 to run more (or less) frequently
G1 can also win its race if it starts collecting earlier. The G1 cycle begins when the heap hits
the occupancy ratio specified by -XX:InitiatingHeapOccupancyPercent= N , which has a
default value of 45. Note that unlike CMS, that setting is based on the usage of the entire
heap, not just the old generation.
The InitiatingHeapOccupancyPercent value is constant; G1 never changes that number
as it attempts to meet its pause time goals. If that value is set too high, the application will
end up performing full GCs because the concurrent phases don't have enough time to com-
plete before the rest of the heap fills up. If that value is too small, the application will per-
form more background GC processing than it might otherwise. As was discussed for CMS,
the CPU cycles to perform that background processing must be available anyway, so the ex-
tra CPU use isn't necessarily important. There can be a significant penalty here, though, be-
cause there will be more of the small pauses for those concurrent phases that stop the applic-
ation threads. Those pauses can add up quickly, so performing background sweeping too fre-
Search WWH ::




Custom Search