Java Virtual Machine (JVM)

 

Overview

The Java Virtual Machine is an interpretive computing engine responsible for executing the byte codes in a compiled Java program. The Java Virtual Machine translates the Java byte codes into the native instructions of the host machine. The appserver, being a Java process, requires a JVM in order to run, and to support the Java applications running on it. JVM settings are part of an application server configuration.

 

Using the JVM

To view and change the JVM configuration for an appserver's process, use the Java Virtual Machine page of the console...

Servers | Application Servers | server_name | Process Definition | Java Virtual Machine

Cycle the appserver after making changes.

 

Configuration tab

Classpath Specifies the standard class path in which the JVM 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 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. The number of garbage collection occurrences are reduced and a 10% gain in performance is realized.

In general, increasing the size of the Java heap improves throughput until the heap no longer resides in physical memory. After the heap begins swapping to disk, Java performance suffers drastically.

Data type Integer
Default 50

Maximum Heap Size 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.

In general, increasing the size of the Java heap improves throughput until the heap no longer resides in physical memory. After the heap begins swapping to disk, Java performance suffers drastically. Set the maximum heap size low enough to contain the heap within physical memory.

Data type Integer
Default 256. 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.

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

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

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

  • -Xnoclassgc

    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

    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, -Xgcthreads=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.

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

    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. Use this argument only with the IBM Developer Kit.

  • -Xgpolicy

    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.

  • -XX

    The Sun-based JDK V1.4.1 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)
    -XX:SurvivorRatio=NewRatioSize

    The default values are:

    NewSize=2m
    MaxNewSize=32m
    SurvivorRatio=2

    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.

  • -server | -client

    Java HotSpot Technology in the Sun-based JDK V1.4.1 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.

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.

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.

 

See Also

Deploy using scripting
Set Custom JVM Properties
Configure appservers for UTF-8 encoding Configure JVM sendRedirect calls to use context root