Java virtual machine settings
Use this page to view and change the Java virtual machine (JVM) configuration for the appserver's process.
To view this administrative console page, click Servers > Application Servers > server > Process Definition > Java Virtual Machine.
Configuration tab
- Classpath
- 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 - Boot Classpath
- 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 - Verbose Class Loading
- Specifies whether to use verbose debug output for class loading.
The default is not to enable verbose class loading.
Data type Boolean Default false - Verbose Garbage Collection
- Specifies whether to use verbose debug output for garbage collection.
The default is not to enable verbose garbage collection.
Data type Boolean Default false - 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.
Data type Boolean Default false - Initial Heap Size
- Specifies the initial heap size available to the JVM code, in megabytes.
Increasing the minimum heap size can improve startup. For WebSphere Application Server, the number of garbage collection occurrences are reduced and a 10% gain in performance is realized.
Data type Integer Default For WebSphere Application Server for z/OS, the default for the Control region is 48, and for the Servant region it is 128. For WebSphere Application Server for iSeries, the default is 96. For all other platforms, the default is 50. - Maximum Heap Size
- Specifies the maximum heap size available to the JVM code, in megabytes.
Increasing the heap size can improve startup. For WebSphere Application Server, by increasing heap size, you can reduce the number of garbage collection occurrences with a 10% gain in performance.
Data type Integer Default 0 for iseries, 256 for all other platforms. Keep the value low enough to avoid paging or swapping-out-memory-to-disk. - 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 you set the Run HProf property to true, then specify command-line profiler arguments as values for the HProf Arguments property.
Data type Boolean Default false - HProf Arguments
- Specifies command-line profiler arguments to pass to the JVM code
that starts the appserver 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.
Data type String - Debug Mode
- 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 specify command-line debug arguments as values for the Debug Arguments property.
Data type Boolean Default false - Debug Arguments
- Specifies command-line debug arguments to pass to the JVM code
that starts the appserver process. You can specify arguments when
Debug Mode is enabled.
Debug arguments are only required if the Debug Mode property is set to true. If you enable debugging on multiple appservers 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 - Generic JVM Arguments
- Specifies command line arguments to pass to the Java virtual machine
code that starts the appserver process.
The following are optional command line arguments that you can use by entering them into the General JVM Arguments field. If you enter more than one argument, separate each argument by a space.
Note: If the argument says it is for the IBM Developer Kit only, you cannot use the argument with another JVM, such as the Sun JDK or the HP JDK.
- -Xquickstart: 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%.
The -Xquickstart option is not supported on OS/400.
- -Xverify:none: When using this value, the class verification stage
is skipped during class loading . By using -Xverify:none with the just
in time (JIT) compiler enabled, startup time is improved by 10-15%.
The -Xverify:none option is not supported on OS/400.
- -Xnoclassgc: You can use this value to disable class garbage collection,
which 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,
disable garbage collection. Class garbage collection is enabled
by default.
- -Xgcthreads: 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.
The -Xgcthreads option is not supported on OS/400.
- -Xnocompactgc: This value disables 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.
- -Xinitsh: You can use this value 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 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.
- -Xgpolicy: You can use this value 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.
- -Xminf: You
can use this value 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%).
- -XX: The Sun-based Java Development Kit (JDK) 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. Objects that survive the first garbage collection cycle are transferred
to another pool. The size of the survivor pool is determined by parameter SurvivorRatio.
If garbage collection becomes a bottleneck, you can try customizing the generation
pool settings. To monitor garbage collection statistics, use the object
statistics in Tivoli Performance Viewer or the verbose:gc configuration setting.
Enter the following values: -XX:NewSize (lower bound) , -XX:MaxNewSize
(upper bound), and -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, 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.
The -XX option is not supported on OS/400.
- -server | -client: Java HotSpot Technology in the Sun-based Java
Development Kit (JDK) 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.
The -server | -client option is not supported on OS/400.
Data type String Units Java command line arguments - -Xquickstart: 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%.
- Executable JAR File Name
- Specifies a full path name for an executable JAR file that the
JVM code uses.
Data type String Units Path name - Disable JIT
- 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 - Operating System Name
- Specifies JVM settings for a given operating system. When started,
the process uses the JVM settings for the operating system of the node.
Data type String
Java virtual machines (JVMs)
Using the JVM
Tuning performance parameter index
Administrative console buttons
Administrative console page features
Custom property collection