Tuning HotSpot Java virtual machines (Solaris & HP-UX)

The architecture of the Sun-developed, HP-ported HotSpot JVM has evolved differently than the IBM-developed software development kit (SDK.) Its internal structure, for young or old generation and permanent regions, arises to primarily support generational garbage collection, as well as other garbage collection modes as necessary.

• Determine the type of JVM on which the appserver is running.

  Issue the java –fullversion command from within the application server APP_ROOT/java/bin directory. In response to this command, the appserver writes information about the JVM, including the JVM provider information, into SystemOut.log. If the appserver is running on an IBM virtual machine for Java , see the topicTuning the IBM virtual machine for Java .

• Verify that the following statements are true for the system:

  1. The most recent supported version of the JVM is installed on the system.

  2. The most recent service update is installed on the system. Almost every new service level includes JVM performance improvements.

Tuning the Sun HotSpot JVM is an iterative process where the JVM configuration is developed, data gathered, primarily from verbosegc data, and then analyzed, and any configuration revisions applied on the next cycle. Perform one or more of the following steps to tune the Sun HotSpot JVM.

 

• Provide enough Java Heap Memory.

  The Java heap memory is a reserved, contiguous set of addresses. The size of the Java heap memory is the maximum size for which the Java heap is configured. These addresses are not available for other native or system memory demands, and are maintained and managed only by the JVM because the Java heap is used for Java object storage for the lifetime of that JVM.

  When the JVM initializes, secures resources for the Java heap are obtained according to the JVM configuration settings. If insufficient memory is available, the JVM initialization fails. If inadequate memory is configured in the Java heap, the system eventually fails with an OutOfMemory report, that is typically preceded by significant garbage collection activity, during which almost no Java processing occurs.

  Sufficient consideration for the native memory needs of other components of the process must be made to accommodate running threads, storing data for I/O, and satisfying such requirements as alignment, and page size. The Sun HotSpot Java heap comprises two physically independent parts that take into consideration when you specify maximum Java heap sizes:

  • The permanent region, which is a combination of young and old generation regions that are further (subdivided into eden, survivor spaces, and tenured regions.

  • The provision memory for the Java components of this system.

  The -XX:MaxPermSize= and -Xmx (Maximum Java Heap size) parameters respectively configure the maximum size of the permanent region, where the class code and related data are logically presented as part of the old generation region but are kept physically separate, and the maximum size of the main heap where Java objects and their data are stored either in the young or old generation regions. Together the permanent region and the main heap comprise the total Java heap. An allocation failure in either of these regions either represents the inability to accommodate either all the application code or all the application data, both of which are terminal conditions, that can exhaust available storage, and cause an OutOfMemory error. Consult these tuning parameters:

  • -XX:MaxPermSize (Permanent region)

  • -Xmx (Maximum Java Heap size)

• Disable explicit garbage collection to eliminate any unnecessary or mistimed major garbage collection cycles that might be introduced in software components of the system. Consult these tuning parameters:

  • -XX:+DisableExplicitGC.

• Tune region sizes to optimize garbage collection action.

  Any garbage collection tuning endeavour decisions should be based on the behavior of the garbage collectors. You should identify the correct garbage collection mode to suit the operational needs of you application. You should also verify that we are meeting the performance requirements, and are efficiently recycling enough memory resources to consistently meet the demands of the application. Any changes that you make to garbage collection parameter settings should produce sufficiently different results and show benefits that are derived from exploiting different regions of the HotSpot Java heap.

  An unwise choice typically lengthens the tuning process as the iterative tuning process needs to be substantially repeated. Further sections present the two principal choices, parallel throughput or concurrent low-pause, and the relevant options for further tuning. Both modes offer the potential for high performance, but the key performance factor is that the behavior that gets optimized is different for each mode. The dominant tuning activity concerns controlling resource utilization to service allocation activity of the application, and to arrange efficient garbage collection to recycle storage, as required. Inevitably, these tuning discussions are dependent on the garbage collection mode employed. Two types of garbage collection are discussed:

  • The throughput collector that performs parallel scavenge copy collection on the young generation. This type of garbage collection is the default type on multi-processor server class machines.

  • A concurrent low-pause collector.

  The objective of tuning with these collectors is to deliver the behavior that is most suited for the allocation patterns and object lifetimes of the application system, and that maximizes the efficiency of their collection actions.

  • Option 1: Use the default throughput/parallel scavenge collector with built-in tuning enabled.

    Starting with V5, the Sun HotSPot JVM provides some detection of the operating system on which the server is running, and the JVM attempts to set up an appropriate generational garbage collection mode, that is either parallel or serial, depending on the presence of multiple processors, and the size of physical memory. It is expected that all of the hardware, on which WAS runs in production and preproduction mode, satisfies the requirements to be considered a server class machine. However, some development hardware might not meet this criteria.

    The behavior of the throughput garbage collector, whether tuned automatically or not, remains the same and introduces some significant pauses, that are proportional to the size of the used heap, into execution of the Java application system as it tries to maximize the benefit of generational garbage collection. However, these automatic algorithms cannot determine if the workload well-suits its actions, or whether the system requires or is better suited to a different garbage collection strategy. Consult these tuning parameters:

    • -XX:+UseParallelGC

    • -XX:+UseAdaptiveSizePolicy

    • -XX:+AggressiveHeap

  • Option 2: Use the default throughput/parallel scavenge collector, but tune it manually.

    Disadvantages of using the built-in algorithm that is established using the -XX:+UseAdaptiveSizePolicy parameter, include limiting what other parameters, such as the -XX:SurvivorRatio parameter, can be configured to do in combination with the built-in algorithm. When you use the built-in algorithm, you give up some control over determining the resource allocations that are used during execution. If the results of using the built-in algorithm are unsatisfactory, it is easier to manually configure the JVM resources, than to try and tune the actions of the algorithm. Manually configuring the JVM resources involves the use of half as many options as it takes to tune the actions of the algorithm. Consult these tuning parameters:

    • -XX:NewRatio=2 This is the default for a server configured for VM mode

    • -XX:MaxNewSize= and -XX:NewSize=

    • -XX:SurvivorRatio=

    • -XX:+PrintTenuringDistribution

    • -XX:TargetSurvivorRatio=

  • Option 3: Use the concurrent low-pause mark-sweep collector

    This collector is a radical departure from the evolution of generational garbage collection that has under pinned the Hotspot architecture, permitting the overlap of application thread processing with a dedicated low-priority, background garbage collection thread. If the application data is incompatible with the behavior of the default throughput collector, then the concurrent mark-sweep (CMS) collector might be a viable strategy, particularly for application systems that are intolerant of invasive pauses. This collector is particularly helpful with the very large heaps that are used with the 64-bit JVM, or applications that have a large set of long-lived data, also referred to as a large tenured generation, and that maintains comparatively good cache utilization, largely preserving pages of the young generation, even while the background thread must scan through all the pages of the entire heap.

    To employ the concurrent mark-sweep collector as the principle housekeeping agent, add this option, instead of any other garbage collection modes, to the JVM configuration.

    Consult these tuning parameters:

    • -XX:+UseConcMarkSweepGC

    • -XX:CMSInitiatingOccupancyFraction=75

    • -XX:SurvivorRatio=6

    • -XX:MaxTenuringThreshold=8

    • -XX:NewSize=128m

    Among the difficulties for tuning with CMS, is that the worst case garbage collection times, which is when the CMS cycle aborts, can take last several seconds, which is especially costly for a system that uses CMS precisely to avoid long pauses. Consequently, service level agreements might dictate the use of CMS, because the average or median pause times are very, very low, and the tuning must err on the cautious side to ensure that CMS cycles don't abort. CMS succeeds only when its anticipatory trigger ensures that the CMS cycle always starts early enough to ensure sufficient free resources are available before they are demanded. If the CMS collector is unable to finish before the tenured generation fills up, the collection is completed by pausing the application threads, which is known as a full collection. Full collections are a sign that further tuning is required to the CMS collector to make it better suit the application.

    Finally, unlike other garbage collection modes with a compaction phase, the use of CMS theoretically raises the risk of fragmentation occurring with the HotSpot. However, in practice this is rarely a problem while the collection recovers a healthy proportion of the heap. In cases when the CMS fails, or aborts a collection, an alternative compacting garbage collection is triggered. Inevitably any other type of garbage collection incurs a significant invasive pause compared to a normal CMS collection.

    Avoid trouble: As with the throughput collector, there are considerably more options available for explicitly controlling CMS. However, those mentioned represent the core of the options that we are likely to need to considered using when we are tuning the HotSpot JVM.

 

Next steps

Gather and analyze data to evaluate the configuration, typically using verbosegc. Continue to gather and analyze data as you make tuning changes until we are satisfied with how the JVM is performing.

Sun HotSpot JVM tuning parameters (Solaris and HP-UX)

 

Related tasks

Tuning the application serving environment