Java virtual machine settings

To view, and change the JVM configuration settings of a process for an application server.

Information	Value
Application server	Servers | Server Types | WebSphere application servers | server_name | Server Infrastructure | Java and process management | Process definition | Java virtual machine
dmgr	System Administration | dmgr | Server Infrastructure | Java and process management | Process definition | Java virtual machine
Node agent	System Administration | Node agent | node_agent | Server Infrastructure | Java and process management | Process definition | Java virtual machine

Classpath

Standard class path in which the Java virtual machine code looks for classes.

If we need to add a classpath to this field, enter each classpath entry into a separate table row. You do not have to add a colon or semicolon at the end of each entry.

The only classpaths that should be added to this field are the ones that specify the location of the following items:

• An inspection or monitoring tool to the system.
• JAR files for a product that runs on top of this product.
• JVM diagnostic patches or fixes.

Processing errors might occur if we add classpaths to this field that specify the location of the following items:

• JAR files for resource providers, such as DB2 . The paths to these JAR files should be added to the relevant provider class paths.

• A user JAR file used by one or more of the applications that you are running on the product.

  The path to this type of JAR file should be specified within each application that requires that JAR file, or in server-associated shared libraries.

• An extension JAR file. If we need to add an extension JAR file to the system, you should use the ws.ext.dirs JVM custom property to specify the absolute path to this JAR file. We can also place the JAR file in the directory...
  WAS_HOME/lib/ext/

  ...but using the ws.ext.dirs JVM custom property is the recommended approach for specifying the path to an extension JAR file.

Information	Value
Data type	String

Boot classpath

Specifies bootstrap classes and resources for JVM code. This option is only available for JVM instructions that support bootstrap classes and resources.

If we need to add a classpath to this field, enter each classpath entry into a table row. You do not need to add the colon or semicolon at the end of each entry.

To add multiple classpaths to this field, we can use either a colon (:) or semi-colon (;), depending on which operating system the node resides, to separate these classpaths.

The only classpaths that should be added to this field are the ones that specify the location of the following items:

• An inspection or monitoring tool to the system.
• JAR files for a product that runs on top of this product.
• JVM diagnostic patches or fixes.

Processing errors might occur if we add classpaths to this field that specify the location of the following items:

• JAR files for resource providers. such as DB2.

  The paths to these JAR files should be added to the relevant provider class paths.

• A user JAR file used by one or more of the applications that you are running on the product.

  The path to this type of JAR file should be specified within each application that requires that JAR file, or in server-associated shared libraries.

• An extension JAR file.

  To add an extension JAR file to the system, you should use the ws.ext.dirs JVM custom property to specify the absolute path to this JAR file. We can also place the JAR file in the directory...

  WAS_HOME/lib/ext/

  ...but using the ws.ext.dirs JVM custom property is the recommended approach for specifying the path to an extension JAR file.

Verbose class loading

Whether to use verbose debug output for class loading. The default is to not enable verbose class loading.

If verbose class loading is enabled, the debug output is sent to one of the native process logs.

Information	Value
Data type	Boolean
Default	false

Verbose garbage collection

Whether to use verbose debug output for garbage collection. The default is not to enable verbose garbage collection.

If verbose garbage collection is enabled, the debug output is sent to one of the native process logs.

Information	Value
Data type	Boolean
Default	false

When this field is enabled, a report is written to the output stream each time the garbage collector runs. This report should give you an indication of how the Java garbage collection process is functioning.

We can check the verboseGC report to determine:

• How much time the JVM is spending performing garbage collection.

  Ideally, we want the JVM to spend less than 5 percent of its processing time doing garbage collection. To determine the percentage of time the JVM spends in garbage collection, divide the time it took to complete the collection by the length of time since the last AF and multiply the result by 100. For example:

  83.29/3724.32 * 100 = 2.236 percent

  If we are spending more than 5 percent of the time in garbage collection and if garbage collection is occurring frequently, we might need to increase the Java heap size.

• If the allocated heap is growing with each garbage collection occurrence.

  To determine if the allocated heap is growing, look at the percentage of the heap that is remains unallocated after each garbage collection cycle, and verify that the percentage is not continuing to decline. If the percentage of free space continues to decline you are experiencing a gradual growth in the heap size from garbage collection to garbage collection. This situation might indicate that the application has a memory leak.

For transitioning users: Version 7.0 and previous versions use the optthruput garbage collection algorithm. In Version 8.0 and later, the default is set to the generational garbage collector. This garbage collection algorithm can increase performance. The following JVM option is added to the WAS startup command: -Xgcpolicy:gencon. If we prefer to use the optthruput garbage collection alogorithm, we can remove -Xgcpolicy:gencon and the optthruput garbage collection algorithm is used.trns

Verbose JNI

Whether to use verbose debug output for native method invocation. The default is not to enable verbose Java Native Interface (JNI) activity.

Information	Value
Data type	Boolean
Default	false

Initial heap size

Specifies, in megabytes, the initial heap size available to the JVM code. If this field is left blank, the default value is used.

Increasing this setting can improve startup. The number of garbage collection occurrences are reduced and a 10 percent gain in performance is achieved.

Increasing the size of the Java heap continues to improves throughput until the heap becomes too large to reside in physical memory. If the heap size exceeds the available physical memory, and paging occurs, there is a noticeable decrease in performance.

Maximum heap size

Specifies, in megabytes, the maximum heap size that is available to the JVM code. If this field is left blank, the default value is used.

The default maximum heap size is 256 MB. This default value applies for both 32-bit and 64-bit configurations.

Increasing the maximum heap size setting can improve startup. When you increase the maximum heap size, you reduce the number of garbage collection occurrences with a 10 percent gain in performance.

Increasing this setting usually improves throughput until the heap becomes too large to reside in physical memory. If the heap size exceeds the available physical memory, and paging occurs, there is a noticeable decrease in performance. Therefore, it is important that the value specified for this property allows the heap to be contained within physical memory.

Best practice: These default values are appropriate for most applications. Enable the Verbose garbage collection property if you think garbage collection is occurring too frequently. If garbage collection is occurring too frequently, increase the maximum size of the JVM heap.

Run HProf

Whether to use HProf profiler support. To use another profiler, specify the custom profiler settings using the HProf Arguments setting. The default is not to enable HProf profiler support.

If we set the Run HProf property to true, then specify command-line profiler arguments as values for the HProf Arguments property.

Information	Value
Data type	Boolean
Default	false

HProf arguments

Specifies command-line profiler arguments to pass to the JVM code that starts the application server process. We can specify arguments when HProf profiler support is enabled.

HProf arguments are only required if the Run HProf property is set to true.

Debug mode

Whether to run the JVM in debug mode. The default is to not enable debug mode support.

If we set the Debug mode property to true, then specify command-line debug arguments as values for the Debug arguments property.

Information	Value
Data type	Boolean
Default	false

Debug arguments

Specifies command-line debug arguments to pass to the JVM code that starts the application server process. We can specify arguments when the Debug mode property is set to true.

If we enable debugging on multiple application servers on the same node, verify that the same value is not specified for the address argument. The address argument defines the port used for debugging. If two servers, for which debugging is enabled, are configured to use the same debug port, the servers might fail to start properly. For example, both servers might still be configured with the debug argument address=7777, which is the default value for the debug address argument.

Information	Value
Data type	String
Units	Java command-line arguments

Generic JVM arguments

Specifies command-line arguments to pass to the Java virtual machine code that starts the application server process.

We can enter the following optional command-line arguments in the Generic JVM arguments field. If we enter more than one argument, enter a space between each argument.

Avoid trouble: If the argument states that it is only for the IBM Developer Kit only, we cannot use that argument with the JVM from another provider, such as the Microsoft or Hewlett-Packardgotcha

• -DhotRestartSync:

  Specify -DhotRestartSync to enable the hot restart sync feature of the synchronization service. This feature indicates to the synchronization service that the installation is running in an environment where configuration updates are not made when the deployment manager is not active. Therefore, the service does not have to perform a complete repository comparison when the deployment manager or node agent servers restart. Enabling this feature improves the efficiency of the first synchronization operation after the deployment manager or a node agent restarts, especially for installations that include mixed release cells, use several nodes, and run several applications.

• (WAS v8.5.0.1)

  
  -Dcom.ibm.crypto.provider.doAESInHardware:

  Set true to enable the Advanced Encryption Standard (AES) function provided with IBM SDK and Runtime Environment for AIX , Java Technology Edition, Version 7. AES is a symmetric block cipher that encrypts and decrypts data through several rounds. Enable this function has resulted in performance improvements in WebSphere Application Server SSL processing.

• -Xquickstart

  Specify-Xquickstart if we want the initial compilation to occur at a lower optimization level than in default mode. Later, depending on sampling results, we can recompile to the level of the initial compile in default mode.

  Best practice: Use-Xquickstart for applications where early moderate speed is more important than long run throughput. In some debug scenarios, test harnesses and short-running tools, we can improve startup time between 15-20 percent.

• -Xverify:none

  Specify-Xverify:none to skip the class verification stage during class loading . Using -Xverify:none disables Java class verification, which can provide a 10-15 percent improvement in startup time. However corrupted or invalid class data is not detected when this argument is specified. If corrupt class data is loaded, the JVM might behave in an unexpected manner, or the JVM might fail.

  Avoid trouble:

  • Do not use this argument if you are making bytecode modifications, because the JVM might fail if any instrumentation error occurs.

  • If we experience a JVM failure or the JVM behaves in an unexpected manner while this argument is in affect, remove this argument as your first step in debugging the JVM problem.

  gotcha

• -Xnoclassgc

  Specify-Xnoclassgc to disable class garbage collection. This argument results in more class reuse and slightly improved performance. However, the resources owned by these classes remain in use even when the classes are not being called.

  The performance impact of class garbage collection is typically minimal, and turning off class garbage collection in a Java EE based system, with its heavy use of application class loaders, might effectively create a memory leak of class data, and cause the JVM to throw an Out-of-Memory Exception.gotcha

  We can use the verbose:gc configuration setting to monitor garbage collection. We can use the resulting output to determine the performance impact of reclaiming these resources.

  If we specify the -Xnoclassgc argument, whenever you redeploy an application, you should always restart the application server to clear the classes and static data from the pervious version of the application.

• -Xgcthreads

  Specify -Xgcthreads to use several garbage collection threads at one time. This garbage collection techniques is known as parallel garbage collection. This argument is valid only for the IBM Developer Kit.

  When entering this value in the Generic JVM arguments field, also enter the number of processors that are running on the machine.

  Specify -Xgcthreads as follows:

  -Xgcthreads<number of processors>

  Avoid trouble: Do not add a space between --Xgcthreads and the n value for the number of processors.

  -Xgcthreads5 is an example of specifying -Xgcthreads with 5 processors. gotcha

  Best practice: You should use parallel garbage collection if the machine has more than one processor.

• -Xnocompactgc

  Specify -Xnocompactgc to disable heap compaction. Heap compaction is the most expensive garbage collection operation. For the IBM Developer Kit, you should avoid heap compaction. If we disable heap compaction, you eliminate all associated overhead.

• -Xgcpolicy

  Specify-Xgcpolicy to set the garbage collection policy. This argument is valid only for the IBM Developer Kit.

  Set this argument to optthruput to optimize throughput, and it does not create a problem if long garbage collection pauses occur.

  Set this argument to gencon, if you are using a generational garbage collector. The generational schema attempts to achieve high throughput along with reduced garbage collection pause times. To accomplish this goal, the heap is split into new and old segments. Long-lived objects are promoted to the old space while short-lived objects are garbage collected quickly in the new space. The gencon policy provides significant benefits for many applications. However, it is not suited for all applications, and is typically more difficult to tune.

  Set this argument to optavgpause, if we want concurrent marking used to track application threads starting from the stack before the heap becomes full. When this parameter is specified, the garbage collector pauses become uniform and long pauses are not apparent. However, using this policy reduces throughput because threads might have to do extra work.

  Set this argument to subpool, if we want to increase performance on multiprocessor systems, that commonly use more then eight processors. This policy is only available on IBM System i , System p , and System z processors. The subpool policy is similar to the optthruput policy except that the heap is divided into subpools that provide improved scalability for object allocation.

• -XX

  The Java Platform, Standard Edition 6 (Java SE 6) has generation garbage collection, which allows separate memory pools to contain objects with different ages. The garbage collection cycle collects the objects independently from one another depending on age. With additional parameters, we can set the size of the memory pools individually. To achieve better performance, set the size of the pool containing objects that have short life cycles, such that the objects in the pool are not kept through more then one garbage collection cycle. Use the NewSize and MaxNewSize parameters to specify the size of the new generation pool.

  Objects that survive the first garbage collection cycle are transferred to another pool. Use theSurvivorRatio parameter to specify the size of the survivor pool.SurvivorRatio. We can use the object statistics that the Tivoli Performance Viewer collects, or include the verbose:gc argument in the configuration setting to monitor garbage collection statistics. If garbage collection becomes a bottleneck, specify the following arguments to customize the generation pool settings to better fit the environment.

  -XX:NewSize=lower_bound  -XX:MaxNewSize=upper_bound
   -XX:SurvivorRatio=new_ratio_size 

  The default values are:

  • NewSize=2m
  • MaxNewSize=32m
  • SurvivorRatio=32

  Best practice: However, if we have a JVM with more than 1 GB heap size, you should use the following values:

  • XX:NewSize=640m
  • XX:MaxNewSize=640m
  • XX:SurvivorRatio=16

  Alternatively, you could set 50% to 60% of the total heap size to a new generation pool.

• -Xminf

  Specify-Xminf to change the minimum free heap size percentage. The heap grows if the free space is below the specified amount. In reset enabled mode, this argument specifies the minimum percentage of free space for the middleware and transient heaps. The valued specified for this argument is a floating point number, 0 through 1. The default is .3 (30 percent).

• -server | -client

  Java HotSpot Technology in Java SE 6 uses an adaptive JVM containing algorithms that, over time, optimize how the byte code performs. The JVM runs in two modes, -server and -client. In most cases, use -server mode, which produces more efficient run-time performance over extended lengths of time.

  If we use the default -client mode, the server startup time is quicker and a smaller memory footprint is created. However, this mode lowers extended performance. Use the -server mode, which improves performance, unless server startup time is of higher importance than performance. We can monitor the process size, and the server startup time to check the performance difference between using the -client and -server modes.

• -Dcom.ibm.CORBA.RequestTimeout=timeout_interval

  Set the timeout period for responding to requests sent from the client. This argument uses the -D option. timeout_interval is the timeout period in seconds. If the network experiences extreme latency, specify a large value to prevent timeouts. If we specify a value that is too small, an application server that participates in workload management can time out before it receives a response.

  Specify this argument only if the application is experiencing problems with timeouts. There are no recommended values for this argument.

• -Dcom.ibm.server.allow.sigkill=true

  The -Dcom.ibm.server.allow.sigkill=true argument allows the node agent process to use the terminate method of a process when the stop method does not complete within the time interval specified for the Ping interval. This setting is useful when the node agent is monitoring an application server and loses contact with that application server.

  When the monitoring policy for the application server allows the node agent to restart the application server because automatic restart is enabled for the application server, the node agent executes the stop method on the application server process. During stop processing, the node agent monitors the application server and if the application server does not stop within the time interval specified for the Ping interval, and this argument is set to true, which is the default value, the node agent executes the terminate method on the application server process to stop the application server process.

  If we set this argument to false, the node agent continues to monitor the stop process, but does not try to restart the application server.

  To use the console to disable this argument, click...

  System Administration | Node agents | nodeagent_name | Java & Process Management | Process Definition | Java Virtual Machine | Generic JVM Arguments

• (WAS v8.5.0.1)

  
  -Dcom.ibm.websphere.alarmthreadmonitor.hung_alarm_mute=

  This argument specifies the maximum number of times an alarm reports its full stack trace in hung-thread messages in the system logs.

  When a system alarm thread is active longer than the alarm thread monitor threshold, the application server logs a hung-thread message with the name of the alarm thread, the length of time that the alarm thread has been active, and the full exception stack trace. The full stack trace is useful for debugging the cause of the delay, but if hung-thread messages are frequently triggered, the repeated long messages can make other information in the system logs hard to find. Set this argument to an integer greater than 0 to specify the maximum number of times any single alarm reports its full stack trace. After this threshold is reached, each subsequent hung-thread message includes only the hung alarm handler's entry.

  The default value of 0 indicates that all hung-thread messages for an alarm include the full stack trace.

  This property specifies a threshold for each alarm handler class, not for the total number of messages or for each alarm handler instance.

• (WAS v8.5.0.1)

  
  -Dcom.ibm.websphere.native.logging.timestamp=true

  Specify this argument to add a time stamp and thread identifier before all server debug messages that are output to the native_stdout and native_stderr log files. We can use the time stamp and thread identifier to correlate the behaviors of application server bootstrap components with the behaviors of other server mechanisms, which are indicated in the SystemOut and SystemErr log files. This behavior is disabled by default.

  When the server is configured with JVM generic argument -Dws.ext.debug=true, it emits debug messages during its bootstrapping sequence to native_stdout.log and native_stderr.log. If -Dcom.ibm.websphere.native.logging.timestamp is also set to true, the server outputs debug messages with a time stamp and thread identifier, as shown in the following example:

  [6/18/12 16:24:31:453 CDT] 00000000  ws.ext.mains.args[0]=-nosplash [6/18/12 16:24:31:453 CDT] 00000000  ws.ext.mains.args[1]=-application
  [6/18/12 16:24:31:453 CDT] 00000000  ws.ext.mains.args[2]=com.ibm.ws.bootstrap.WSLauncher
  [6/18/12 16:24:31:453 CDT] 00000000  ws.ext.mains.args[3]=com.ibm.ws.runtime.WsServer

  You should specify -Dws.ext.debug=true only under the direction of IBM support personnel.

• -Dcom.ibm.websphere.wlm.unusable.interval=interval

  This argument only applies for z/OS. Specify the -Dcom.ibm.websphere.wlm.unusable.interval= timeout_interval argument to change the value of the com.ibm.websphere.wlm.unusable.interval property when the workload management state of the client is refreshing too soon or too late. This property specifies, in seconds, the amount of time that the workload management client run time waits after it marks a server as unavailable before it attempts to contact the server again. This argument uses the -D option. The default value is 300 seconds. If the property is set to a large value, the server is marked as unavailable for a long period of time. This prevents the workload management refresh protocol from refreshing the workload management state of the client until after the time period has ended.

• -Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=

  This argument only applies for z/OS. Specify the -Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl= argument to indicate that storage for individual direct byte buffers should be released as soon as the buffer is no longer needed. The only supported value for this argument is com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl.

  The direct byte buffers, that the JVM creates to handle request data, are allocated in the Language Environment (LE) heap instead of in the JVM heap. Typically, even if the direct byte buffers are no longer needed, the JVM does not release this native LE storage until the next garbage collection occurs. If the server is handling large requests, LE storage might become exhausted before the JVM runs a garbage collection cycle, causing the server to abnormally terminate (abend). Configuring the JVM with the following argument prevents these abends from occurring.

  -Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl

  On the z/OS platform, we also need to specify this argument if specified thezaioFreeInitialBuffers custom property for a TCP channel to have the channel release the initial read buffers used on new connections as soon as these buffers are no longer needed for the connection.

• -DisSipComplianceEnabled=true|false

  Whether SIP compliance checking is enabled in the SIP proxy server. SIP compliance checking ensures that the SIP messages conform to the Session Initiation Protocol standard. When true, SIP compliance checking is enabled.

  Avoid trouble: If we are running a proxy server in a z/OS WebSphere Application Server Network Deployment environment, and the proxy server is not part of a cluster, we can use the isSipComplianceEnabled SIP proxy server custom property to enable or disable SIP compliance checking for that SIP proxy server. However if you are running a stand-alone application server or the proxy server is part of a cluster, use this generic JVM argument to enable or disable SIP compliance checking.gotcha

• -Xshareclasses:none

  Specify the-Xshareclasses:none argument to disable class sharing for a JVM process. Class sharing, which is available with Java SE 6 and later and enabled by default, enables multiple JVM processes to share classes that were previously loaded and stored in the cache. The cache resides in shared memory and persists across JVM restarts. All WebSphere Application Server processes that run on JVMs, such as application servers, node agents, and deployment managers, can use class sharing to improve startup time and reduce memory footprint.

  Occasionally, the shared class cache must be cleared, such as when you modify application code or when you upgrade WebSphere Application Server. To clear the cache, call the <app_server_root>/bin/clearClassCache.bat (or clearClassCache.sh) utility. On z/OS, restarting the system also clears the cache.

  Before using the clearClassCache utility, stop all of the attached JVMs.

  Avoid trouble:

  Not supported on Solaris, HP, and IBM i.

  • Java EE application classes running in an application server process are not added to the shared class cache.

  gotcha

• XXallowvmshutdown:false

  Use the -XXallowvmshutdown:false argument to revert to a previous behavior for the JVM that is not correct. Java 5.0 SR10 and Java 6 SR5 correct issues in which the JVM does not shut down correctly. If we have an application that depends on the old behavior, we can revert to the previous behavior by adding the this argument to the Generic JVM arguments section.

Information	Value
Data type	String
Units	Java command-line arguments

Executable JAR file name

Specifies a full path name for an executable JAR file that the JVM code uses.

Information	Value
Data type	String
Units	Path name

Disable JIT

Whether to disable the just-in-time (JIT) compiler option of the JVM code.

If we disable the JIT compiler, throughput decreases noticeably. Therefore, for performance reasons, keep JIT enabled.

Information	Value
Data type	Boolean
Default	false (JIT enabled)
Recommended	JIT enabled

Operating system name

Specifies JVM settings for a given operating system.

When the process starts, the process uses the JVM settings specified for the node as the JVM settings for the operating system.

Related tasks

Configure the JVM

Tune the application serving environment

Custom property collection

Process logs