Skip navigation.
Downloads | Product Documentation | Support

Tuning WebLogic JRockit with WebLogic Server on Linux

# Running WebLogic JRockit JVM with WebLogic Server on Linux

This section describes how to start up and configure the BEA WebLogic JRockit JVM. It also provides some background on selecting and running both a thread system and a memory management system (called a "garbage collector"). This section includes information the following subjects:

- Starting BEA WebLogic JRockit
- Configuring WebLogic JRockit JVM by Using Command Line Options
- Using a Thread System
- Using a Memory Management System (Garbage Collection)

# Starting BEA WebLogic JRockit

You can start BEA WebLogic JRockit either from the command line or from the WebLogic Server's Node Manager. This section describes both methods.

## Starting BEA WebLogic JRockit JVM from the Command Line

Before starting WebLogic JRockit JVM, ensure that you have the following directory set in your PATH environment variable:

>     <jrockit-install-directory>/bin

(where `<jrockit-install-directory>` is the folder where you installed WebLogic JRockit, such as c:`/bea/jrockit81_141_02/`.)

To start the JVM, at the command line enter on of the following:

>     java

and any tuning or configuration and tuning options you want to use; for example, you might start WebLogic JRockit JVM with the following command string:

>     java -verbose -Xgc:gencopy -Xms:64 -Xmx:512 -Xns:64 -Xnopt myClass

Here, the standard configuration parameter `-Verbose` requests verbose output from the system and the non-standard option `-Xgc:gencopy` sets the generational copying memory management system (the "garbage collector"). The tuning parameters -Xms:64 and -Xmx:512 set the minimum (`-Xms`) and maximum (`-Xmx`) heap sizes, while the tuning parameter `-Xns:64` set the size of the young generation (the "nursery"; required for generational collectors). `myClass` identifies the class that contains the `main()` method and is required whenever you start WebLogic JRockit.

All of the options in this example—along with others—are described in Configuring WebLogic JRockit JVM by Using Command Line Options, below, or in Tuning WebLogic JRockit JVM with WebLogic Server on Linux.

Note: You can also start JRockit from the command by specifying a fully-qualified path to the file; for example, enter:

`<jrockit-install-directory>`/bin/java

## Starting BEA WebLogic JRockit from the Node Manager

You can also start WebLogic JRockit JVM from the WLS Node Manager. To do this, access the Node Manager and go to the Remote Start Page. In the Java Home field, enter the fully-qualifying path, as suggested in the example above. For more information on using the Node Manager, please see Overview of Node Manager in Configuring and Managing WebLogic Server.

# Configuring WebLogic JRockit JVM by Using Command Line Options

Configure WebLogic JRockit JVM by using a number of standard and non-standard command line options that you enter at startup. These options work with WebLogic JRockit on all supported operating systems; none are specific to Linux.

If you start WebLogic JRockit JVM from the Remote Start page of the WLS Node Manager, simply enter the options, with the appropriate arguments, in the Arguments field on the Remote Start page. For more information on using the Node Manager,please see Overview of Node Manager in Configuring and Managing WebLogic Server. This section describes:

- Standard Command Line Options for:

- Presenting General Information Options
- Setting Logging Options

- Non-standard Command Line Options for:

- Setting Behavioral Options
- Displaying Logging Information

## Standard Command Line Options

Standard command line configuration options work the same regardless of the JVM; in other words, these options work the same whether you are running WebLogic JRockit JVM, Sun Microsystem's HotSpot JVM, or any other third-party JVM.

### Presenting General Information Options

The following standard command line options set general information about WebLogic JRockit JVM:

- `-classpath <`directories and zips/jars separated by `:>`

Tells the VM where to look for classes and resources. Alternately, you can use the option `-cp` to represent `-classpath`; for example:

`-cp <`directories and zips/jars separated by `:>`

- `-D<name>[=<value>]`

Tells the VM to set a Java system property. These can be read by a Java program, using the methods in `java.lang.System`.

### Setting Logging Options

The following options determine if the system will provide messages to the operator and what the form and content of those messages should be.

- `-version`

Tells JRockit to display its product version number and then exit.

- `-showversion`

Tells the VM to display its product version number and then continue.

- `-verbose[:<`components separated by `,>]`

Tells JRockit to display verbose output. This option is used mainly for debugging purposes and causes a lot of output to the console. Supported components are `memory`, `load` and `codegen`. If no component is given, JRockit will display verbose information on everything.

- `-help`

Tells the VM to display a short help message.

- `-X`

Tells the VM to display a short help message on the extended options.

## Non-standard Command Line Options

The non-standard, or `-X`, command line options are options that are exclusive to WebLogic JRockit JVM that change the behavior of WebLogic JRockit JVM to better suit the needs of different Java applications. Non-standard options are used extensively with thread system and memory management. These options normally won't work on other JVMs (conversely, the non-standard options used by other JVMs normally won't work with WebLogic JRockit).

Warning: Since these options are non-standard, they are subject to change at any time.

### Setting Behavioral Options

The following non-standard options define general WebLogic JRockit JVM behavior:

- `-Xnoopt`

Tells the VM not to optimize code.

- `-Xverify`

Tells the VM to do complete bytecode verification.

### Displaying Logging Information

>     -Xverbose

`-Xverbose` causes WebLogic JRockit to print to the screen specific information about the system. The information displayed depends upon the parameter specified with the option; for example, specifying the parameter `cpuinfo` displays information about your CPU and indicates whether or not the JVM can determine if hyper threading is enabled. The valid parameters for `-Xverbose` are: .

- `codegen —` The names of each method that is being compiled.
- `cpuinfo``—` Any interesting information about your CPUs.
- `load —` The names of each loaded class.
- `memory; gc —` Information about the memory management system, including:

- Start time of collection (seconds since JVM start)
- End time of collection (seconds since JVM start)
- Memory used by objects before collection (KB)
- Memory used by objects after collection (KB)
- Size of heap after collection (KB)
- Total time of collection (seconds or milliseconds)
- Total pause time during collection (milliseconds)
- The information displayed by -Xverbose:memory or -Xverbose:gc will vary depending upon the type of garbage collector you are using.

- `opt —` Information about all methods that get optimized.

For descriptions and examples of the information these parameters display, please refer to Table 3-1 in Starting and Configuring WebLogic JRockit JVM (found in Using WebLogic JRockit 8.1 SDK).

# Using a Thread System

The thread system allows WebLogic JRockit JVM to take optimal advantage of the underlying operating system. WebLogic JRockit JVM supports two types of thread systems:

- Native Threads, which maps Java threads directly to the operating system threads, taking advantage of the operating system's thread scheduling and load balancing policies. Native Threads is the default thread system for WebLogic JRockit JVM.
- Thin Threads, wherein multiple Java threads are run on a singe operating system thread. This allows WebLogic JRockit JVM to optimize thread scheduling, thread switching, and thread synchronization, while using less memory.

Warning: Thin threads is experimental functionality in this version of WebLogic JRockit SDK and is not recommended for general use. This feature is subject to change without notice.

For more information on native and thin threads and on how to select a thread system that best meets your needs, please refer to Choosing the Thread System in Using WebLogic JRockit 8.1 SDK.

To start a thread system, include one of the options listed in Table 2-1 when you start WebLogic JRockit JVM:

Table 2-1 Thread System Implementation Options

To Use... | Use this Option...
--- | ---
Native Threads | `-Xnativethreads` This option is the default.
Thin Threads | `-Xthinthreads` This option is not available on IA64.

# Using a Memory Management System (Garbage Collection)

WebLogic JRockit JVM manages memory by employing four different garbage collectors. These collectors work during runtime to clear the memory heap of expired objects, or "garbage." The four garbage collectors are:

- Generational Copy, which divides the memory into two areas called "generations." Instead of allocating objects in one single space and garbage collecting that whole space when it gets full, most of the objects are allocated in the "young generation," called the nursery.
- Single-Spaced Concurrent, one of two types of concurrent collectors, which does its work in parallel with ordinary processing; that is, it does not stop all Java threads to do the complete garbage collection. This is designed to support garbage collection without disruption and to improve multiprocessor garbage collection performance.
- Generational Concurrent is the second type of concurrent collector WebLogic JRockit employs. Although very similar to a single-spaced concurrent collector, a generational concurrent garbage collector does its actual object allocation in a "nursery," reducing the need to do collection of the entire heap so often.
- Parallel garbage collection, which stops all Java threads and uses all CPUs to perform a complete garbage collection of the entire heap.

For information and tips on selecting a garbage collector, please refer to Choosing a Garbage Collection Method in Using WebLogic JRockit 8.1 SDK.

## Starting a Garbage Collector

To start a garbage collector, simply include at the command line the `-Xgc` option and the type of collector you want to use, as shown in Table 2-2.

Table 2-2 Garbage Collector Implementation Options

To select... | Enter...
--- | ---
Generational Copying | `-Xgc:gencopy`
Single Spaced Concurrent | `-Xgc:singlecon`
Generational Concurrent | `-Xgc:gencon`
Parallel | `-Xgc:parallel`

When started, JRockit will run with the specified garbage collector.

### Default

If the garbage collector has not been set and the maximum heap size (set by using `-Xmx` or by using the default, as described in Setting the Maximum Heap Size) is less than 128 MB, the default garbage collector is generational copying (`-Xgc:gencopy`); otherwise the default is parallel (`-Xgc:parallel`).

## Printing a Comprehensive Report

>     -Xgcreport

`-Xgcreport` causes WebLogic JRockit JVM to print a comprehensive garbage collection report at program completion. The option `-Xgcpause` causes the VM to print a line each time Java threads are stopped for garbage collection. Combining the two is a very good way of examining the memory behavior of your application.