Java virtual machine settings

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

If you 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.

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

If you 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.

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

Specifies 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.

Specifies 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.

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.

On the z/OS platform, you can also issue the MVS™ console command, modify display, jvmheap, to display JVM heap information. In addition, you can check the server activity and interval SMF records. The JVM heap size is also made available to PMI and can be monitored using the Tivoli® Performance Viewer.

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

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

For z/OS, the default initial heap size for the controller is 48 MB, and the default initial heap size for the servant is 128 MB. These default values apply for both 32-bit and 64-bit configurations.

For IBM i and distributed platforms, the default initial heap size is 50 MB.

Avoid trouble: For IBM i, the initial heap size must always be less than the maximum heap size. Never set the initial heap size and maximum heap size properties to the same value.

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.

Specifies, in megabytes, the maximum heap size that is available to the JVM code. If this field is 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 you specify for this property allows the heap to be contained within physical memory.

To prevent paging, specify a value for this property that allows a minimum of 256 MB of physical memory for each processor and 512 MB of physical memory for each application server. If processor utilization is low because of paging, increase the available memory, if possible, instead of increasing the maximum heap size. Increasing the maximum heap size might decrease performance rather than improving performance.

Specifies 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 you set the Run HProf property to true, then you must specify command-line profiler arguments as values for the HProf Arguments property.

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

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

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

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

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

If you 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 that is 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.

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

-DhotRestartSync:

Specify -DhotRestartSync if you want 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.

-Dcom.ibm.crypto.provider.doAESInHardware:

Set this option to true if you want to enable the Advanced Encryption Standard (AES) function that is 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. Enabling this function results in performance improvements in WebSphere Application Server SSL processing.

-Xquickstart

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

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, you can improve startup time 15 - 20 percent.

-Xverify:none

Specify-Xverify:none if you want 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 corrupted class data is loaded, the JVM might behave in an unexpected manner, or the JVM might fail.

Do not use this argument if you are making bytecode modifications because the JVM might fail if any instrumentation error occurs. If you experience a JVM failure or the JVM behaves in an unexpected manner while this argument is in effect, remove this argument as your first step in debugging your JVM problem.

-Xnoclassgc

Specify-Xnoclassgc if you want to disable class garbage collection. This argument results in more class reuse and slightly improved performance. However, the resources that are 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 Platform, Enterprise Edition (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.

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

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

Avoid trouble: You must use the -noclassgc argument to disable class garbage collection on this platform.

-Xgcthreads

Specify -Xgcthreads if you want 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 your 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.

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

Avoid trouble: IBM i does not support this argument.

-Xnocompactgc

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

Avoid trouble: IBM i does not support this argument.

-Xgcpolicy

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

Set this argument to optthruput if you want 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 you 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 you 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.

Avoid trouble: IBM i does not support this argument.

-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, you 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. You can use the object statistics that the Tivoli Performance Viewer collects, or include the verbose:gc argument in your 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 your 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 you 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.

Avoid trouble: IBM i does not support this argument.

-Xminf

Specify-Xminf if you want to change the minimum free heap size percentage. The heap grows if the free space is less than 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).

Avoid trouble: IBM i does not support this argument.

-Dcom.ibm.CORBA.RequestTimeout=timeout_interval

Specify the -Dcom.ibm.CORBA.RequestTimeout= timeout_interval argument to 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 your network experiences extreme latency, specify a large value to prevent timeouts. If you 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 your application is experiencing problems with timeouts. There are no recommended values for this argument.

-Dcom.ibm.CORBA.RequestTimeout=timeout_interval

Specify the -Dcom.ibm.CORBA.RequestTimeout= timeout_interval argument to 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 your network experiences extreme latency, specify a large value to prevent timeouts. If you 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 your 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 you 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 administrative console to disable this argument, click System Administration > Node agents > nodeagent_name > Java & Process Management > Process Definition > Java Virtual Machine > Generic JVM Arguments.

-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.

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

-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. You 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

Important: Specify -Dws.ext.debug=true only under the direction of IBM support personnel.

-Dcom.ibm.ws.wim.registry.DbSharedAcrossMultipleServers=true

Specify -Dcom.ibm.ws.wim.registry.DbSharedAcrossMultipleServers=true when Virtual member manager (VMM) DB/LA repositories are shared across different installations. This property is not for use in clustered environments. Setting this property allows VMM to synchronize calls from WebSphere Application Server installations who share repositories.

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

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

You also need to specify this argument if you specify 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

Specifies 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 this property is set to true, SIP compliance checking is enabled.

Avoid trouble: If you are running a proxy server in a z/OS WebSphere Application Server Network Deployment environment, and your proxy server is not part of a cluster, you 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 your proxy server is part of a cluster, you must use this generic JVM argument to enable or disable SIP compliance checking.

-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, run the clearClassCache script from the directory, <app_server_root>/bin/.

./clearClassCache.sh

clearClassCache.bat

clearClassCache

Restarting the system also clears the cache.

Note: Before you use the clearClassCache script, you must stop all of the attached JVMs. See clearClassCache script for more information on using the clearClassCache script.

Avoid trouble:

• Class sharing and its associated settings are not supported on:
  • Solaris
  • HP-UX

-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 Java virtual machine (JVM) does not shut down correctly. If you have an application that depends on the old behavior, you can revert to the previous behavior by adding the this argument to the Generic JVM arguments section.

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

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

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

Specifies JVM settings for a given operating system.

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