Java Reference
In-Depth Information
Normally the G1 region size needs to be tuned only to handle humongous object allocation, but
there is one other case where it might need to be tuned.
Consider an application that specifies a very large heap range, e.g., -Xms2G -Xmx32G . In that case,
the region size will be 1 MB. When the heap is fully expanded, there will be 32,000 G1 regions.
That is a lot of separate regions to process; the G1 algorithm is designed around the idea that the
number of regions is closer to 2,048. Increasing the size of the G1 region will make G1 a little
more efficient in this example; select a value so that there will be close to 2,048 regions at the ex-
pected heap size.
G1 allocation of humongous objects
If the G1 region size is 1 MB and a program allocates an array of 2 million bytes, the array
will not fit within a single G1 region. But these humongous objects must be allocated in con-
tiguous G1 regions. If the G1 region size is 1 MB, then to allocate a 3.1 MB array, G1 must
find four contiguous regions within the old generation in which to allocate the array. (The
rest of the last region will remain empty, wasting 0.9 MB of space.) This defeats the way G1
normally performs compaction, which is to free arbitrary regions based on how full they are.
Often, G1 will have to perform a full GC in order to find contiguous regions.
Because the humongous object is allocated directly in the old generation, it cannot be freed
during a young collection. So if the object is short-lived, this also defeats the generational
design of the collector. The humongous object will be collected during the concurrent G1
cycle. On the bright side, the humongous object can be freed quickly since it is the only ob-
ject in the regions it occupies. Humongous objects are freed during the cleanup phase of the
concurrent cycle (rather than during a mixed GC).
Increasing the size of a G1 region so that all objects the program will allocate can fit within a
single G1 region can make G1 more efficient.
To determine if humongous object allocation is causing the full GCs in a particular applica-
tion, the GC log must have adaptive size policy logging enabled. When the application alloc-
ates a humongous object, G1 will first attempt to start a concurrent cycle:
5.349: [G1Ergonomics (Concurrent Cycles) request concurrent cycle initiation,
reason: occupancy higher than threshold, occupancy: 483393536 bytes,
allocation request: 524304 bytes, threshold: 483183810 bytes (45.00 %),
source: concurrent humongous allocation]
Search WWH ::

Custom Search