IBM Power System POWER7 Series, Optimization And Tuning Manual

Page: 148 / 224

132
POWER7 and Optimization and Tuning Guide
Although the Java heap is a contiguous range of memory addresses, any region within that
range can be committed or released as required. This situation enables the balanced
collector to contract the heap more dynamically and aggressively than other garbage
collectors, which typically require the committed portion of the heap to be contiguous. Java
heap configuration for
-Xgcpolicy:balanced strategy can be specified through the -Xmn ,
-Xmx , and -Xms options.
7.4.5 Optimal heap size
By default, the JVM provides a considerably flexible heap configuration that allows the heap
to grow and shrink dynamically in response to the needs of the application. This configuration
allows the JVM to claim only as much memory as necessary at any time, thus cooperating
with other processes that are running on the system. The starting and maximum size of the
heap can be specified with the
-Xms and -Xmx options.
This flexibility comes at a cost, as the JVM must request memory from the operating system
whenever the heap must grow and return memory whenever it shrinks. This behavior can
lead to various unwanted scenarios. If the application heap requirements oscillate, this
situation can cause excessive heap growth and shrinkage.
If the JVM is running on a dedicated machine, the processing impact of heap resizing can be
eliminated by requesting a constant sized heap. This situation can be accomplished by
setting
-Xms
equal to
-Xmx
. Choosing the correct size for the heap is highly important, as GC
impact is directly proportional to the size of the heap. The heap must be large enough to
satisfy the application's maximum memory requirements and contain extra space. The GC
must work much harder when the heap is near full capacity because of fragmentation and
other issues, so 20 - 30% of extra space above the maximum needs of the application can
lower the overall GC impact.
If an application requires more flexibility than can be achieved with a constant sized heap, it
might be beneficial to tune the sizing parameters for a dynamic heap. One of the most
expensive GC events is
object allocation failure . This failure occurs when there is not enough
contiguous space in the current heap to satisfy the allocation, and results in a GC collection
and a possible heap expansion. If the current heap size is less than the
-Xmx size, the heap is
expanded in response to the allocation failure if the amount of free space is below a certain
threshold. Therefore, it is important to ensure that when an allocation fails, the heap is
expanded to allow not only the failed allocation to succeed, but also many future allocations,
or the next failed allocation might trigger yet another GC collection. This situation is known as
heap thrashing .
The -Xminf , -Xmaxf , -Xmine , and -Xmaxe group of options can be used to affect when and how
the GC resizes the heap. The -Xminf<
factor
> option (where factor is a real number
0 - 1) specifies the minimum free space in the heap; if the total free space falls below this
factor, the heap is expanded. The
-Xmaxf<
factor
> option specifies the maximum free space;
if the total free space rises above this factor, the heap is shrunk. These options can be used
to minimize heap thrashing and excessive resizing. The
-Xmine and -Xmaxe options specify
the minimum and maximum sizes to shrink and grow the heap by. These options can be used
to ensure that the heap has enough free contiguous space to allow it to satisfy a reasonable
number of allocations before failure.
Regardless of whether the heap size is constant, it should never be allowed to exceed the
physical memory available to the process; otherwise, the operating system might have to
swap data in and out of memory. An application's memory behavior can be determined by
using various tools, including verbose GC logs. For more information about verbose GC logs
and other tools, see “Java (either AIX or Linux)” on page 176.