Use this page to view and change the 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: For i5/OS and distributed platforms WebSphere Application Server Network Deployment:
| Application server | Servers > Application Servers > server1. Then, under Server Infrastructure, click Java and Process Management > Process Definition > Java Virtual Machine |
| Deployment manager | System Administration > Deployment Manager. Then, under Server Infrastructure, click Java and Process Management > Process Definition > Java Virtual Machine |
| Node agent | System Administration > Node Agent > nodeagent. Then, under Server Infrastructure, click Java and Process Management > Process Definition > Java Virtual Machine |
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 |
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 idea of what is going on with Java garbage collection. Key things to look for in a verboseGC report are:
83.29/3724.32 * 100 = 2.236%
If you are spending more than 5% of your time in GC and if GC is occurring frequently, you may need to increase your Java heap size.
To determine this, look at the %free. You want to make sure the number is not continuing to decline. If the %free continues to decline you are experiencing a gradual growth in allocated heap from GC to GC which could indicate that your application has a memory leak.
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.
For i5/OS, the minimum heap size must always be less than the maximum heap size. Never set the minimum heap size and maximum heap size properties to the same value.
| Data type | Integer |
| Default |
For i5/OS, the default is 96 |
For the majority of applications these defaults should work quite well.
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 specify a value for this property that allows a minimum of 256MB 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 heap size might make performance worse rather than better.
For i5/OS, when this property is set to 0 (zero), the garbage collector runs only when the garbage collector threshold has been reached. When a value other than 0 is specified, the garbage collector runs whenever the heap size reaches the specified maximum size. However, unlike a normal garbage collector, if the maximum size is reached, all application threads must wait until the garbage collection process has finished before they can continue running. This might cause undesirable pause times. Therefore, you should use the maximum heap size as a safety net to handle times of unexpected heap growth and to ensure that the heap doesn't grow larger than the available memory. Under normal circumstances, the specified maximum heap size should never be reached.
| Data type | Integer |
| Default |
For i5/OS, the default is 0, which indicates that no maximum heap size is set. |
For the majority of applications these defaults should work quite well. You can monitor the frequency of garbage collection by enabling Verbose garbage collection field. If garbage collection is occurring too frequently you should increase the maximum size of the JVM heap.
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 |
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.
| Data type | String |
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 |
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. The following are optional command line arguments that you can enter in the Generic JVM arguments field. If you enter more than one argument, enter a space between each argument.
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.
| 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 |
Specifies whether to use verbose debug output for garbage collection. The default is not to enable verbose garbage collection.
| Data type | Boolean |
| Default | false |
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 idea of what is going on with Java garbage collection. Key things to look for in a verboseGC report are:
83.29/3724.32 * 100 = 2.236%
If you are spending more than 5% of your time in GC and if GC is occurring frequently, you may need to increase your Java heap size.
To determine this, look at the %free. You want to make sure the number is not continuing to decline. If the %free continues to decline you are experiencing a gradual growth in allocated heap from GC to GC which could indicate that your application has a memory leak.