User Guide

Starting and Configuring BEA JRockit JVM

This section describes how to start BEA JRockit and how to configure it by using standard and non-standard command line options. It includes information on the following subjects:

Note: If JRockit behaves in some unexpected way, please consult the BEA JRockit Developers FAQ. If that doesn't solve your problem, please send an e-mail to support@bea.com.

Before Starting BEA JRockit

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

<jrockit-install-directory>/bin (for Linux)
<jrockit-install-directory>\bin (for Windows)

Starting BEA JRockit

To start the BEA JRockit, at the command line enter the following:

java <configuration and tuning options> myClass

Where <configuration and tuning options> are the configuration and tuning options you want to use. The configuration options are described in Configuring BEA JRockit, below. See Tuning BEA JRockit JVM for details on the tuning options available for this version of BEA JRockit.

Note: You can alternatively start JRockit with by fully qualifying the path to the file; for example, /usr/local/java/bin/java (depending on where it is installed) on Linux and c:\bea\jrockitxxx\bin\java (depending on where its installed) on Windows.

Sample Start-up Command

A sample start-up command, with some tuning options specified, might look like this:

java -verbose:memory -Xgcprio:throughput -Xmx:256m -Xms:64m -Xns:24m myClass

In this example, the following options are set:

-verbose:memory—Displays verbose output about memory usage.
-Xgcprio:throughput—A dynamic garbage collector prioritized for memory throughput will be used.
-Xmx:256m—The maximum heap size is set to 256 megabytes.
-Xms:64m—The initial heap size is set to 64 megabytes.
-Xns:24m-—The nursery size is set to 24 megabytes.
myClass—Identifies the class that contains the Main() method.

For more information on the tuning options discussed above, please refer to

Configuring BEA JRockit

When you start BEA JRockit, you can set behavioral parameters by using either standard or non-standard command line options. This section describes these options and how to use them at startup to configure BEA JRockit. It contains information on the following subjects:

Using Standard Options for:

Using Non-standard Options for:

Special Instructions for Linux Users

Using Standard Options

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

Setting the JVM Type

The following commands set the type of JVM you want to run, server-side or client-side:

-server

Starts BEA JRockit JVM as a server-side JVM. This value is the default.

-client

Starts BEA JRockit JVM as a client-side JVM. This option is helpful if you have a smaller heap and are anticipating shorter runtimes for your application.

You should be aware that setting the JVM type (or accepting the default) will also set the garbage collection algorithm that will be used during runtime. -server will start a single-spaced, parallel mark, parallel sweep collector while -client will start a a single-spaced, concurrent mark, concurrent sweep garbage collector. If you want to use a different collector, such as the dynamic, unified garbage collector or one of the specific fixed garbage collectors, you can override the default by using either the -Xgcprio or -Xgc command line options. For more information on garbage collection and the -server and -client options, please refer to Using -server and -client to Set a Fixed Garbage Collector in Using BEA JRockit Memory System.

Setting General Information

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

-classpath <directories and zips/jars separated by : (Linux) or ; (Windows)>

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 : or ;>

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

Providing Information to the User

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, gc, opt, and codegen. If no component is given, JRockit will display verbose information on everything. For more information on the components and the -verbose information they display, please refer to Table 2-1.

-help

Tells the VM to display a short help message.

-X

Tells the VM to display a short help message on the extended options (do not confuse -X with the non-standard, or -X, options described in the following section).

Using Non-standard Options

Non-standard, or -X, command line options are options that are exclusive to BEA JRockit JVM that change the behavior of BEA JRockit JVM to better suit the needs of different Java applications. These options are all preceded by -X and will not work on other JVMs (conversely, the non-standard options used by other JVMs won't work with BEA JRockit).

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

Setting Behavioral Options

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

-Xnoopt

Tells the VM not to optimize code.

-Xverify

Tells the VM to do complete bytecode verification.

-Xstrictfp

Enables strict floating point arithmetics globally for all methods in all classes. This option is similar to the Java keyword strictfp. See the Java Language Specification for more details on strictfp.

Displaying Logging Information

-Xverbose

-Xverbose causes BEA 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. Table 2-1 lists the parameters available for -Xverbose.

Note: To use more than one parameter, separate them with a comma; for example:

-Xverbose:gc,opt

Table 2-1 -Xverbose Parameters

This Parameter...	Prints to the screen...
`codegen`	The names of each method that is being compiled. Verbose output for `codegen` might look like this: `[codegen] 0 : 17.9411 ms [codegen] 0 68592131 1 java.lang.Object.unlockFatReal_jvmpi (Ljava.lang.Object;Ljava.lang.Thread;I)V: 17.94 ms [codegen] 1 : 2.0262 ms [codegen] 0 0 2 java.lang.Object.acquireMonitor(Ljava.lang.Object;II)I: 19.97 ms [codegen] 2 : 4.4926 ms [codegen] 0 10 3 java.lang.Object.unlockFat(Ljava.lang.Object;Ljava.lang.Thread;I)V: 24.46 ms [codegen] 3 : 0.3328 ms`
`cpuinfo`	Any interesting information about your CPUs. Verbose output for `cpuinfo` might look like this: `[cpuinfo] Vendor: GenuineInt [cpuinfo] Type: Original OEM [cpuinfo] Family: Pentium Pro [cpuinfo] Model: Pentium III/Pentium III Xeon [cpuinfo] Brand: Pentium III processor [cpuinfo] Supports: On-Chip FPU [cpuinfo] Supports: Virtual Mode Extensions [cpuinfo] Supports: Debugging Extensions [cpuinfo] Supports: Page Size Extensions`
`load`	The names of each loaded class. Verbose output for `load` might look like this: `[load ] 0 1 java.lang.Object+ [load ] 0 2 java.io.Serializable+ [load ] 0 3 java.lang.Class+ [load ] 0 5 java.lang.reflect.AccessibleObject+ [load ] 0 6 java.lang.reflect.Member+ [load ] 0 6 java.lang.reflect.Method+`
`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.
`memory; gc` with `gencon`	A report for a JVM running a generational concurrent collector (`-Xgc:gencon`) with `memory` or `gc` specified might look like this: [memory ] Generational Concurrent collector [memory ] nursery 20480K, heap 65536K, maximal heap 262144K [memory ] <start>: Nursery GC <before>K-><after>K (<heap>K), <total> ms [memory ] <s>-<end>: GC <before>K-><after>K (<heap>K), <total> s (<pause> ms) [memory ] <s/start> - start time of collection (seconds since jvm start) [memory ] <end> - end time of collection (seconds since jvm start) [memory ] <before> - memory used by objects before collection (KB) [memory ] <after> - memory used by objects after collection (KB) [memory ] <heap> - size of heap after collection (KB) [memory ] <total> - total time of collection (seconds or milliseconds) [memory ] <pause> - total pause time during collection (milliseconds) Now running The GcList Test [memory ] 0.860: Nursery GC 61615K->42008K (86016K), 11.400 ms [memory ] 0.953: Nursery GC 62488K->42876K (86016K), 10.895 ms [memory ] 1.031: Nursery GC 63356K->45303K (86016K), 30.156 ms [memory ] 1.172: Nursery GC 65783K->46168K (86016K), 11.639 ms [memory ] 1.250: Nursery GC 66648K->48596K (86016K), 31.189 ms The execution of The GcList Test took 0.578s
`memory; gc` with `singlecon`	A report for a JVM running a single generation concurrent collector (`-Xgc:singlecon`) with `memory` or `gc` specified might look like this: [memory ] Single Generation Concurrent collector [memory ] heap 65536K, maximal heap 262144K [memory ] <s>-<end>: GC <before>K-><after>K (<heap>K), <total> s (<pause> ms) [memory ] <s/start> - start time of collection (seconds since jvm start) [memory ] <end> - end time of collection (seconds since jvm start) [memory ] <before> - memory used by objects before collection (KB) [memory ] <after> - memory used by objects after collection (KB) [memory ] <heap> - size of heap after collection (KB) [memory ] <total> - total time of collection (seconds or milliseconds) [memory ] <pause> - total pause time during collection (milliseconds) Now running The GcList Test [memory ] 1.016-1.172: GC 58543K->13906K (89716K), 0.156 s (3.420 ms) The execution of The GcList Test took 0.563s Now running The GcList Test [memory ] 1.422-1.469: GC 102004K->389K (122816K), 0.047 s (5.048 ms)
`memory; gc` with `parallel`	A report for a JVM running a parallel collector (`-Xgc:parallel`) with `memory` or `gc` specified might look like this: [memory ] Parallel collector [memory ] heap 65536K, maximal heap 262144K [memory ] <start>: GC <before>K-><after>K (<heap>K), <total> ms [memory ] <start> - start time of collection (seconds since jvm start) [memory ] <before> - memory used by objects before collection (KB) [memory ] <after> - memory used by objects after collection (KB) [memory ] <heap> - size of heap after collection (KB) [memory ] <total> - total time of collection (milliseconds) Now running The GcList Test [memory ] 1.016: GC 65536K->1463K (65536K) in 12.933 ms The execution of The GcList Test took 0.500s Now running The GcList Test [memory ] 1.282: GC 65536K->1502K (65536K) in 11.046 ms [memory ] 1.563: GC 65536K->1503K (65536K) in 12.119 ms The execution of The GcList Test took 0.484s Now running The GcList Test [memory ] 1.782: GC 65536K->593K (65536K) in 9.365 ms The execution of The GcList Test took 0.125s
`opt`	Information about all methods that get optimized. Verbose output for `opt` might look like this: `[opt ] 280 2434 0 ObjAlloc.main([Ljava.lang.String;)V: 0.00 ms [opt ] 0 : 9.8996 ms`

This Parameter...

Prints to the screen...

codegen

The names of each method that is being compiled. Verbose output for codegen might look like this:

[codegen] 0 : 17.9411 ms [codegen] 0 68592131 1 java.lang.Object.unlockFatReal_jvmpi (Ljava.lang.Object;Ljava.lang.Thread;I)V: 17.94 ms [codegen] 1 : 2.0262 ms [codegen] 0 0 2 java.lang.Object.acquireMonitor(Ljava.lang.Object;II)I: 19.97 ms [codegen] 2 : 4.4926 ms [codegen] 0 10 3 java.lang.Object.unlockFat(Ljava.lang.Object;Ljava.lang.Thread;I)V: 24.46 ms [codegen] 3 : 0.3328 ms

cpuinfo

Any interesting information about your CPUs. Verbose output for cpuinfo might look like this:

[cpuinfo] Vendor: GenuineInt [cpuinfo] Type: Original OEM [cpuinfo] Family: Pentium Pro [cpuinfo] Model: Pentium III/Pentium III Xeon [cpuinfo] Brand: Pentium III processor [cpuinfo] Supports: On-Chip FPU [cpuinfo] Supports: Virtual Mode Extensions [cpuinfo] Supports: Debugging Extensions [cpuinfo] Supports: Page Size Extensions

load

The names of each loaded class. Verbose output for load might look like this:

[load ] 0 1 java.lang.Object+ [load ] 0 2 java.io.Serializable+ [load ] 0 3 java.lang.Class+ [load ] 0 5 java.lang.reflect.AccessibleObject+ [load ] 0 6 java.lang.reflect.Member+ [load ] 0 6 java.lang.reflect.Method+

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.

memory; gc

with gencon

A report for a JVM running a generational concurrent collector (-Xgc:gencon) with memory or gc specified might look like this:

[memory ] Generational Concurrent collector [memory ] nursery 20480K, heap 65536K, maximal heap 262144K [memory ] <start>: Nursery GC <before>K-><after>K (<heap>K), <total> ms [memory ] <s>-<end>: GC <before>K-><after>K (<heap>K), <total> s (<pause> ms) [memory ] <s/start> - start time of collection (seconds since jvm start) [memory ] <end> - end time of collection (seconds since jvm start) [memory ] <before> - memory used by objects before collection (KB) [memory ] <after> - memory used by objects after collection (KB) [memory ] <heap> - size of heap after collection (KB) [memory ] <total> - total time of collection (seconds or milliseconds) [memory ] <pause> - total pause time during collection (milliseconds) Now running The GcList Test [memory ] 0.860: Nursery GC 61615K->42008K (86016K), 11.400 ms [memory ] 0.953: Nursery GC 62488K->42876K (86016K), 10.895 ms [memory ] 1.031: Nursery GC 63356K->45303K (86016K), 30.156 ms [memory ] 1.172: Nursery GC 65783K->46168K (86016K), 11.639 ms [memory ] 1.250: Nursery GC 66648K->48596K (86016K), 31.189 ms The execution of The GcList Test took 0.578s

memory; gc

with singlecon

A report for a JVM running a single generation concurrent collector (-Xgc:singlecon) with memory or gc specified might look like this:

[memory ] Single Generation Concurrent collector [memory ] heap 65536K, maximal heap 262144K [memory ] <s>-<end>: GC <before>K-><after>K (<heap>K), <total> s (<pause> ms) [memory ] <s/start> - start time of collection (seconds since jvm start) [memory ] <end> - end time of collection (seconds since jvm start) [memory ] <before> - memory used by objects before collection (KB) [memory ] <after> - memory used by objects after collection (KB) [memory ] <heap> - size of heap after collection (KB) [memory ] <total> - total time of collection (seconds or milliseconds) [memory ] <pause> - total pause time during collection (milliseconds) Now running The GcList Test [memory ] 1.016-1.172: GC 58543K->13906K (89716K), 0.156 s (3.420 ms) The execution of The GcList Test took 0.563s Now running The GcList Test [memory ] 1.422-1.469: GC 102004K->389K (122816K), 0.047 s (5.048 ms)

memory; gc

with parallel

A report for a JVM running a parallel collector (-Xgc:parallel) with memory or gc specified might look like this:

[memory ] Parallel collector [memory ] heap 65536K, maximal heap 262144K [memory ] <start>: GC <before>K-><after>K (<heap>K), <total> ms [memory ] <start> - start time of collection (seconds since jvm start) [memory ] <before> - memory used by objects before collection (KB) [memory ] <after> - memory used by objects after collection (KB) [memory ] <heap> - size of heap after collection (KB) [memory ] <total> - total time of collection (milliseconds) Now running The GcList Test [memory ] 1.016: GC 65536K->1463K (65536K) in 12.933 ms The execution of The GcList Test took 0.500s Now running The GcList Test [memory ] 1.282: GC 65536K->1502K (65536K) in 11.046 ms [memory ] 1.563: GC 65536K->1503K (65536K) in 12.119 ms The execution of The GcList Test took 0.484s Now running The GcList Test [memory ] 1.782: GC 65536K->593K (65536K) in 9.365 ms The execution of The GcList Test took 0.125s

opt

Information about all methods that get optimized. Verbose output for opt might look like this:

[opt ] 280 2434 0 ObjAlloc.main([Ljava.lang.String;)V: 0.00 ms [opt ] 0 : 9.8996 ms

Including a Timestamp with Logging Information

-Xverbosetimestamp

You can force a timestamp to print out with other information generated by -Xverbose by using the command -Xverbosetimestamp. When you use this command, the time and date will precede the verbose information, as shown here:

[Wed Jan 14 16:51:57 2004][14578][load   ]created: java/lang/Integer : 1.4034ms

Protecting Systems by Using the Security Manager

BEA JRockit allows its own Management Console, JRA, and other tools, to connect to running processes through its own proprietary interface. You can open a port on the VM that can only connect to the tools that run locally on your system and not allow a connection from other tools running anywhere else on the network. This allows authorized users to access the production system and run the tool locally so they can monitor or attach to a running BEA JRockit instance, without exposing a security hole for non-authorized users to invade production systems.

To do this, you need to run the JVM with a security manager and grant access to the management server from the host(s) to which you choose to grant privileges. Use this procedure:

Run BEA JRockit with -Djava.security.manager.

In the policy file, grant the appropriate permissions, as shown in the following code sample:

grant {
   permission java.net.SocketPermission "localhost:7090", "*";
}

Preventing BEA JRockit JVM (When Run as a Service) from Shutting Down After Receiving a Logoff Event

When BEA JRockit JVM is run as a service (for example, the servlet engine for a web server), it might receive CTRL_LOGOFF_EVENT or SIGHUP. Upon receiving such events, if the VM tries to initiate shutdown, it will fail, since the operating system will not actually terminate the process. To avoid possible interference such as this, use the -Xnohup command-line option. When this option is used with BEA JRockit, the JVM does not watch for or process CTRL_LOGOFF_EVENT or SIGHUP events.

If you specify -Xnohup, be aware of the following:

Pressing Ctrl-Break to create a thread dump does not work.
User code is responsible for causing shutdown hooks to run; for example by calling System.exit() when BEA JRockit is to be terminated.

Special Instructions for Linux Users

If you are running BEA JRockit on either a 32- or 64-bit Linux machine, two additional configuration options allow you to enable core dumps on Red Hat AS and to select one of two thread libraries for any Linux version. This information is described below.

Enabling Core Dumps on Red Hat AS

If you are using Red Hat AS and want to ensure that a core/javacore file is created in the working directory in the event BEA JRockit crashes, you need to enable core dumps. To do this, set the ulimit -c value to something greater than zero, but no greater than a value your filesystem can accommodate; for example, ulimit -c 10000000. These values are measured in blocks, with each block equaling one kilobyte. You can set the ulimit value either from the command line, in the *.profile file, or in a shell script.

Overriding NPTL

The Native POSIX Thread Library (NPTL) is a thread library option available for use instead of LinuxThreads with Red Hat Enterprise Linux 3.0. If you want to disable NPTL and use LinuxThreads, set LD_ASSUME_KERNEL=2.4.1 in your environment.