Configuration and Setup of SAP JVM 
After installing a NetWeaver Application Server Java system, there is generally not much to do to configure the SAP JVM, as it comes preconfigured to match the workload of typical server tasks. Changes to the default configuration should only be done if there is a clearly identified problem and the consequences of parameter settings are fully understood.
Garbage Collection and Memory Layout
One area where some configuration effort can be advantageous under certain circumstances is the choice of a garbage collector (GC) matching the application requirements and – closely connected – the partitioning of the available working memory. The following section gives a short overview of this topic and some hints and advice on useful parameters.
Generational GC
It has been empirically observed that in many programs, the most recently created objects are also those most likely to become unreachable quickly (known as infant mortality or the generational hypothesis). A generational GC divides objects into generations. The young generation contains the recently created objects. Objects which survive some young generation collections (sometimes they are called small GC) are copied (promoted) to the old generation. The permanent generation contains class metadata.
Usually objects are allocated in the young generation, the so called “eden” space. If an allocation fails (the eden is full) all Java threads are halt and a young generation GC is invoked. All surviving objects in the young generation (eden and from space) are copied to the “to” space. “To” and “from” space are switched afterwards. If the “to” space is filled, objects are copied to the old generation. The “tenuring threshold” specifies the amount of copy steps inside the young generation before an object is promoted to the old generation.
The old generation is collected when a promotion fails. The permanent and the old generation are usually collected together. During this collection the Java threads are halted.
Procedure
Choosing a GC algorithm
The young generation is collected by a “copy collector”. As described above objects are copied from “eden” and “from” to “to” space and then to the old generation. The cost of this GC is determined by the amount of objects to be copied. The workload can be distributed among a number of parallel GC threads, which speeds up the GC on multi CPU machines. Usually the pause time of a young generation collection is between some ten milliseconds and some hundred milliseconds.
The old generation is collected by a mark sweep (compact) collector. The GC time depends on the fill level of the old generation and the amount of objects swept. The GC time is roughly about 1-4s per GB. This would lead to long pause time for an ordinary stop-the-world collector. The SAP JVM offers two different old generation collectors. A stop-the-world collector, which collects and compact the old generation with several GC threads (-XX:+UseParallelOldGC) and a mostly concurrent collector, which does most of the marking and sweeping concurrently to the application execution (-XX:+UseConcMarkSweepGC). Latter cannot compact the heap. Hence it could be that a promotion of a large object fails and a fallback to a compacting stop-the-world collector is invoked. To avoid these long running stop-the-world GCs the SAP JVM starts the concurrent old generation collection when the old generation is 80% filled.
Recommendation
For response time critical applications we recommend to use the concurrent mark sweep collector and for throughput driven application we recommend the parallel old generation collector. The SAP JVM automatically chooses an appropriate (parallel) young generation collector that can work with the chosen old generation collector.
For completeness: -XX:+UseParallelGC is a parallel young generation collector, which can be used together with -XX:+UseParallelOldGC.
Option -XX:+UseParNewGC can be used in combination with -XX:+UseConcMarkSweepGC.
Configuring the Heap and Garbage Collector
The following graphic gives an overview of the heap parameters.
Heap Parameters and their effect on memory partition
As depicted in the graphic, the following options are relevant for the GC configuration:
-Xmx<size>: maximum size of the Java heap
-Xms<size>: initial heap size
-XX:MaxPermSize=<size>: maximum size of permanent generation
-XX:PermSize=<size>: initial size of the permanent generation
-XX:MaxNewSize=<size>: maximum size of the young generation
-XX:NewSize=<size>: initial size of the young generation
-XX:ParallelGCThreads=<val>: number of threads used by the GC
-XX:MaxTenuringThreshold=<val>: maximum number of copies inside the young generation before promotion
-XX:SurvivorRatio=<val>: ratio between eden and one survivor space. The eden is <val> times bigger than a survivor space
-XX:TargetSurvivorRatio=<val>: desired fill level in % of a survivor space. The SAP JVM automatically adjusts the tenuring threshold (only ParNewGC)
-XX:SoftRefLRUPolicyMSPerMB=<value>: threshold in ms per free MB for clearing unreferenced SoftReferences
-XX:GCHeapFreeLimit=<value>
minimum percentage of free space after a full GC before an OutOfMemoryError is thrown. Default value: 10.
-XX:GCTimeLimit=<value>
limit of proportion of time spent in GC before an OutOfMemoryError is thrown. Default value: 90
-XX:{+-}UseGCOverheadLimit
use policy to limit of proportion of time spent in GC before an OutOfMemory error is thrown. Default value: +.
For more information on monitoring the GC, see Monitoring and Management.
Setting the Debug Port Range
For security reasons, it is strongly advisable to restrict the access to the debugging port range of a running SAP JVM. Using the debugging protocol, everyone that is able to connect to the VM effectively gains complete control over the VM and can change its behavior as well as read sensitive information.
For this reason, the debugging port range and the port used by jvmmond (if running) should be protected, e.g., by using a firewall.
The default debugging port range of an SAP JVM is 8000 – 8100 and can be customized by the VM parameter -XdebugPortRange:<from>[-<to>].
The debugging port of an SAP JVM running in an application server node is derived using the formula:
5${INSTANCE_NUMBER}20 + ${NODE_INDEX} * 5 + 1
This can be configured in the AS Java Config Tool by changing the value for the key DebugPort in the VM Environment tab.
Note
The debug port range can be changed at runtime as well by using the jvmmon-gui tool. If a jvmmond is running, the port used to connect to this daemon (which is given at the jvmmond start command line) should be firewall-protected as well.