Java virtual machine settings

To view this administrative console page, connect to the administrative console and navigate to the Java virtual machine panel.

Information	Value
Application server	Servers | Server Types | WebSphere Application Servers | server | Server Infrastructure section | Java and process management | Process definition | Java virtual machine
Deployment manager	System Administration | Deployment manager | 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 add a classpath to this field, enter each classpath entry into a separate table row. We 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 must be added to the relevant provider class paths.

• A user JAR file used by one or more of the applications that we are running on the product. The path to this type of JAR file must be specified within each application that requires that JAR file, or in server-associated shared libraries.

• An extension JAR file. If add an extension JAR file to the system, 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 WAS_HOME/lib/ext/ directory, but the recommended approach for specifying the path to an extension JAR file is to use the ws.ext.dirs JVM custom property.

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 add a classpath to this field, enter each classpath entry into a table row. We do not need to add the colon or semicolon at the end of each entry.

If 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 must be added to the relevant provider class paths.

• A user JAR file used by one or more of the applications that we are running on the product. The path to this type of JAR file must be specified within each application that requires that JAR file, or in server-associated shared libraries.

• An extension JAR file. If add an extension JAR file to the system, 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 WAS_HOME/lib/ext/ directory, but the recommended approach for specifying the path to an extension JAR file is to use the ws.ext.dirs JVM custom property.

Verbose class loading

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

(Dist) 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

Specifies whether to use verbose debug output for garbage collection. The default is to enable verbose garbage collection.

If verbose garbage collection is enabled, the debug output is sent to 10 rotating verbosegc log files, which can contain about 7000 garbage collection cycles, with an approximate size of 10 M. For the z/OS platform, the verbosegc logs are written to the configuration file system. The performance overhead of verbose garbage collection is negligible.

Information	Value
Data type	Boolean
Default	true

To revert the logging behavior for verbose garbage collection to that of releases or fix packs earlier than 9.0.0.3, disable verbose garbage collection and enter the standard JVM option -verbose:gc as a generic JVM argument. This option directs the JVM to send the debug output to a native process log. We can enter extra non-standard JVM options as generic JVM arguments to customize the logging behaviors of verbose garbage collection.

When this field is enabled, a report is written to the output stream each time the garbage collector runs. This report gives 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 on garbage collection.

  Ideally, we want the JVM to spend less than 5 percent of its processing time on garbage collection. To determine the percentage of time the JVM spends in garbage collection, divide the time that 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 our time in garbage collection and if garbage collection is occurring frequently, we might need to increase your Java heap size.

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

  To determine whether the allocated heap is growing, look at the percentage of the heap that remains unused after each garbage collection cycle. Verify that the percentage is not continuing to decline. If the percentage of free space continues to decline, we 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.

(ZOS) On the z/OS platform, we can also issue the MVS console command, modify display, jvmheap, to display JVM heap information. In addition, we 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.

Verbose JNI

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

(ZOS) For z/OS, the default initial heap size for the controller is 256 MB, and the default initial heap size for the servant is 512 MB.

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

These default values are sufficient for most applications.bprac

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 improve throughput until the heap becomes too large to be 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 available to the JVM code. If this field is left blank, the default value is used.

The default maximum heap size is 25% of the total amount of system memory up to 4 GB, or the JVM default whenever memory size is inaccessible.

Increasing the maximum heap size setting can improve startup. When we 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 be 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 we specify for this property allows the heap to be contained within physical memory.

(ZOS) For z/OS, the default maximum heap size for the controller is 512 MB, and the default maximum heap size for the servant is 1024 MB. 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 use 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.

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

Run HProf

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

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.

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

• (Dist) -DhotRestartSync:

  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 to enable the Advanced Encryption Standard (AES) function provided with IBM SDK and Runtime Environment for AIX, Java Technology Edition, v7. 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

  The initial compilation occurs 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.

  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 15 - 20 percent.bprac

  IBM i does not support this argument.

• -Xverify:none

  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 we are making bytecode modifications because the JVM might fail if any instrumentation error occurs.

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

  • (iSeries) IBM i does not support this argument.

• -Xnoclassgc

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

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

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

  IBM i does not support this argument. We must use the -noclassgc argument to disable class garbage collection on this platform.

• -Xgcthreads

  Use several garbage collection threads at one time. This garbage collection technique is known as parallel garbage collection. This argument is valid only for the IBM Developer Kit.

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

  Specify -Xgcthreads as follows:

  -Xgcthreads<number of processors>

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

  -Xgcthreads5 is an example of specifying -Xgcthreads with five processors.

  We must use parallel garbage collection if the machine has more than one processor.bprac

  IBM i does not support this argument.

• -Xnocompactgc

  Disable heap compaction. Heap compaction is the most expensive garbage collection operation. If we are using the IBM Developer Kit, we must avoid heap compaction. If we disable heap compaction, you eliminate all associated overhead.

  IBM i does not support this argument.

• -Xgcpolicy

  Set the garbage collection policy. This argument is valid only for the IBM Developer Kit.

  optthruput	Maximum throughput. Use if long garbage collection pauses are not an issue.
  gencon	Generational garbage collector. 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.
  optavgpause	Use concurrent marking to track application threads that start 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.
  balanced	Uses mark, sweep, compact and generational style garbage collection. The concurrent mark phase is disabled; concurrent garbage collection technology is used, but not in the way that concurrent mark is implemented for other policies. The balanced policy uses a region-based layout for the Java heap. These regions are individually managed to reduce the maximum pause time on large heaps and increase the efficiency of garbage collection. The policy tries to avoid global collections by matching object allocation and survival rates. If we have problems with application pause times that are caused by global garbage collections, particularly compactions, this policy might improve application performance. If we are using large systems that have Non-Uniform Memory Architecture (NUMA) characteristics (x86 and POWER platforms only), the balanced policy might further improve application throughput.

• -XX

  The garbage collection cycle collects the objects independently from one another depending on age. With extra 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 lifecycles, such that the objects in the pool are not kept through more than one garbage collection cycle. Use the NewSize and MaxNewSize parameters to specify the size of the new generational 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. 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 generational 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

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

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

  bprac

  Alternatively, we might set 50% to 60% of the total heap size to a new generational pool.

  IBM i does not support this argument.

• -Xminf

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

  IBM i does not support this argument.

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

  IBM i does not support this argument.

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

  Allow the node agent process to use the terminate method of a process when the stop method does not complete within the time interval that is 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. 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 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. Hoever, 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.

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

  Add a time stamp and thread identifier before all server debug messages that are output to the native_stdout and native_stderr log files. 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
  

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

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

  Specify true when Virtual member manager (VMM) DB/LA repositories are shared across different installations. This property is not for use in clustered environments. Setting true allows VMM to synchronize calls from WAS installations who share repositories.

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

  This argument applies for z/OS only. Specify if 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 is 300 seconds. If the property is set to a large value, the server is marked as unavailable for a long time. This prevents the workload management refresh protocol from refreshing the workload management state of the client until after the time period finishes.

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

  This argument applies for z/OS only. Specify to indicate that storage for individual direct byte buffers must 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

  (ZOS) On the z/OS platform, you also need to specify this argument if we 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 true, SIP compliance checking is enabled.

  If we are running a proxy server in a z/OS WAS ND environment, and your 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 we are running a stand-alone application server or your proxy server is part of a cluster, we must use this generic JVM argument to enable or disable SIP compliance checking.

• -Xshareclasses:none

  Disable the share classes option for a process. Sharing classes in a cache can improve startup time and reduce memory footprint. Processes, such as application servers, node agents, and deployment managers, can use the share classes option.

  If we use this option, we must clear the cache when the process is not in use. To clear the cache, either call the <app_server_root>/bin/clearClassCache.bat utility or stop the process and then restart the process.

  When we use clearClassCache, to clear the entire cache we must stop all of the attached JVMs.

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

• -XXallowvmshutdown:false

  Use the -XXallowvmshutdown:false argument to revert to a previous behavior for the JVM that is not correct. If we have an application that depends on the old behavior, we can revert to the previous behavior by adding 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

Specifies 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 that are specified for the node as the JVM settings for the operating system.

1. Balanced garbage collection as a new option
2. Configure the JVM
3. Tune the application serving environment
4. Custom property collection
5. Process logs