Use this page to view and change the Java virtual machine (JVM) configuration settings of a process for an application server.
To view this administrative console page, connect to the administrative console and navigate to the Java Virtual Machine panel:
Application server | Servers > Application Servers > server1 > Java and Process Management > Process Definition > Java Virtual Machine |
Deployment manager | System Administration > Deployment Manager > Java and Process Management > Process definition > Java Virtual Machine |
Node agent | System Administration > Node Agent > nodeagent > Java and Process Management > Process definition > Java Virtual Machine |
Configuration tab
Specifies the standard class path in which the Java virtual machine code looks for classes.
Enter each classpath entry into a table row. You do not need to add the colon or semicolon at the end of each entry.
Data type | String |
Units | Class path |
Specifies bootstrap classes and resources for JVM code. This option is only available for JVM instructions that support bootstrap classes and resources. You can separate multiple paths by a colon (:) or semi-colon (;), depending on operating system of the node.
Data type | String |
Specifies whether to use verbose debug output for class loading. The default is not to enable verbose class loading.
Data type | Boolean |
Default | false |
Specifies whether to use verbose debug output for garbage collection. The default is not to enable verbose garbage collection.
Data type | Boolean |
Default | false |
Specifies whether to use verbose debug output for native method invocation. The default is not to enable verbose Java Native Interface (JNI) activity.
Data type | Boolean |
Default | false |
Specifies the initial heap size available to the JVM code, in megabytes.
Increasing the minimum heap size can improve startup. The number of garbage collection occurrences are reduced and a 10% gain in performance is realized.
Increasing the size of the Java heap improves throughput until the heap no longer resides in physical memory, in general. After the heap begins swapping to disk, Java performance suffers drastically.
Data type | Integer |
Default | For distributed platforms, the default is 50. |
Specifies the maximum heap size available to the JVM code, in megabytes.
Increasing the heap size can improve startup. By increasing heap size, you can reduce the number of garbage collection occurrences with a 10% gain in performance.
Increasing the size of the Java heap usually improves throughput until the heap no longer resides in physical memory. When the heap size exceeds the physical memory, the heap begins swapping to disk which causes Java performance to drastically decrease. Therefore, it is important to set the maximum heap size to a value that allows the heap to be contained within physical memory.
To prevent paging, you should allow a minimum of 256MB of physical memory for each processor and 512 MB of physical memory for each application server. If possible, adjust the available memory when paging occurs if processor utilization is low because of this paging.
Data type | Integer |
Default | 256. Keep the value low enough to avoid paging or swapping-out-memory-to-disk. |
Specifies whether to run the JVM in debug mode. The default is not to 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.
Data type | Boolean |
Default | false |
Specifies command-line debug arguments to pass to the JVM code that starts the application server process. You can specify arguments when Debug Mode is enabled.
For WebSphere Application Server Network Deployment configurations, Debug arguments are only required if the Debug Mode property is set to true. If you enable debugging on multiple application servers on the same node, make sure that the servers are using different address arguments, which define the port for debugging. For example, if you enable debugging on two servers and leave the default debug port for each server as address=7777, the servers could fail to start properly.
Data type | String |
Units | Java command-line arguments |
Specifies command line arguments to pass to the Java virtual machine code that starts the application server process.
You can use -Xquickstart for initial compilation 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 between 15-20%.
You can use -Xverify:none if you want to skip the class verification stage during class loading . Using -Xverify:none with the just in time (JIT) compiler enabled, improves startup time by 10-15%.
You can use -Xnoclassgc to disable class garbage collection. This action leads to more class reuse and slightly improved performance. The trade-off is that you won't be collecting the resources owned by these classes. You can monitor garbage collection using the verbose:gc configuration setting, which will output class garbage collection statistics. Examining these statistics will help you understand the trade-off between the reclaimed resources and the amount of garbage collection required to reclaim the resources. However, if the same set of classes are garbage collected repeatedly in your workload, you should disable garbage collection. Class garbage collection is enabled by default.
You can use several garbage collection threads at one time, also known as parallel garbage collection. When entering this value in the Generic JVM Arguments field, also enter the number of processors that your machine has, for example, -Xgcthreadsn, where n is the number of processors. On a node with n processors, the default number of threads is n. You should use parallel garbage collection if your machine has more than one processor. This argument is valid only for the IBM Developer Kit.
You can use -Xnocompactgc to disable heap compaction, which is the most expensive garbage collection operation. Avoid compaction in the IBM Developer Kit. If you disable heap compaction, you eliminate all associated overhead.
You can use -Xinitsh to set the initial heap size where class objects are stored. The method definitions and static fields are also stored with the class objects. Although the system heap size has no upper bound, set the initial size so that you do not incur the cost of expanding the system heap size, which involves calls to the operating system memory manager. You can compute a good initial system heap size by knowing the number of classes loaded in the WebSphere Application Server product, which is about 8,000 classes, and their average size. Having knowledge of the applications helps you include them in the calculation. You can use this argument only with the IBM Developer Kit.
You can use -Xgpolicy to set the garbage collection policy. If the garbage collection policy (gcpolicy) is set to optavgpause, concurrent marking is used to track application threads starting from the stack before the heap becomes full. The garbage collector pauses become uniform and long pauses are not apparent. The trade-off is reduced throughput because threads might have to do extra work. The default, recommended value is optthruput. Enter the value as -Xgcpolicy:[optthruput|optavgpause]. You can use this argument only with the IBM Developer Kit.
The Sun-based Java Development Kit (JDK) Version 1.4.2 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 short lived objects so that objects in the pool do not live through more then one garbage collection cycle. The size of new generation pool is determined by the NewSize and MaxNewSize parameters.
-XX:NewSize (lower bound) -XX:MaxNewSize (upper bound) -XX:SurvivorRatio=NewRatioSize
The default values are:NewSize=2m MaxNewSize=32m SurvivorRatio=2. However, if you have a JVM with more than 1 GB heap size, you should use the values: -XX:newSize=640m -XX:MaxNewSize=640m -XX:SurvivorRatio=16, or set 50 to 60% of total heap size to a new generation pool.
You can use -Xminf to specify the minimum free heap size percentage. The heap grows if the free space is below the specified amount. In reset enabled mode, this option specifies the minimum percentage of free space for the middleware and transient heaps. This is a floating point number, 0 through 1. The default is .3 (30%).
Java HotSpot Technology in the Sun-based Java Development Kit (JDK) Version 1.4.2 introduces an adaptive JVM containing algorithms for optimizing byte code execution over time. The JVM runs in two modes, -server and -client. If you use the default -client mode, there will be a faster startup time and a smaller memory footprint, but lower extended performance. You can enhance performance by using -server mode if a sufficient amount of time is allowed for the HotSpot JVM to warm up by performing continuous execution of byte code. In most cases, use -server mode, which produces more efficient run-time execution over extended periods. You can monitor the process size and the server startup time to check the difference between -client and -server.
You can use -Dcom.ibm.CORBA.RequestTimeout=timeout_interval to specify 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.
Be careful specifying this property; it has no recommended value. Set it only if your application is experiencing problems with timeouts.
You can use -Dcom.ibm.websphere.wlm.unusable.interval=interval to change the value for the com.ibm.websphere.wlm.unusable.interval property if the workload management state of the client is refreshing too soon or too late. This property specifies the time interval 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. interval is the time in seconds between attempts. 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.
Data type | String |
Units | Java command line arguments |
Specifies a full path name for an executable JAR file that the JVM code uses.
Data type | String |
Units | Path name |
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.
Data type | Boolean |
Default | false (JIT enabled) |
Recommended | JIT enabled |
Specifies JVM settings for a given operating system.
For the Network Deployment product, when the process starts, the process uses the JVM settings for the node as the JVM settings for the operating system.
Data type | String |
Runtime tab
Related concepts
Java virtual machines (JVMs)
Related tasks
Configuring the JVM
Tuning the application serving environment
Related reference
Custom property collection