Using WebLogic JRockit 8.1 SDK

Starting and Configuring WebLogic JRockit JVM

This section describes how to start WebLogic 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 WebLogic JRockit Developers FAQ. If that doesn't solve your problem, please send an e-mail to support@bea.com.

Before Starting WebLogic JRockit

Before starting WebLogic 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 WebLogic JRockit

To start the WebLogic 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 WebLogic JRockit, below. See Tuning WebLogic JRockit JVMfor details on the tuning options available for this version of WebLogic 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 -Xgc:gencopy -Xmx:256m -Xms:64m -Xns:24m myClass

In this example, the following options are set:

-verbose:memory—Displays verbose output about memory usage.
-Xgc:gencopy—A generational copy garbage collector 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 WebLogic JRockit

When you start WebLogic 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 WebLogic JRockit. It contains information on the following subjects:

Using Standard Options for:

Using Non-standard Options for:

Enabling Core Dumps on Linux

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 WebLogic JRockit JVM, Sun Microsystem's HotSpot JVM, or any other third-party JVM.

Setting General Information

The following standard command line options set general information about WebLogic 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 3-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 below).

Using Non-standard Options

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. 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 WebLogic 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 WebLogic 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 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. Table 3-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 3-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
`memory; gc` with `gencopy`	A report for a JVM running a Generational Copying collector (`-Xgc:gencopy`) with `memory` or `gc` specified might look like this: [memory ] Generational Copying collector [memory ] nursery 640K, to/fromspace 32768K, pinnedspace 4K [memory ] maximal heap 131712-262144K [memory ] <start>: Nursery GC <before>K-><after>K (<heap>K), <total> ms [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 ] 0.828: Nursery GC 298K->212K (33596K), 1.561 ms [memory ] 0.859: Nursery GC 852K->532K (33596K), 3.637 ms [memory ] 0.859: Nursery GC 1172K->852K (33596K), 3.639 ms [memory ] 0.875: Nursery GC 1492K->1172K (33596K), 3.600 ms [memory ] 0.875: Nursery GC 1812K->1492K (33596K), 3.665 ms [memory ] 0.891: Nursery GC 2132K->1812K (33596K), 3.620 ms [memory ] 0.891: Nursery GC 2452K->2132K (33596K), 3.610 ms [memory ] 0.906: Nursery GC 2772K->2452K (33596K), 3.720 ms [memory ] 0.906: Nursery GC 3092K->2772K (33596K), 4.307 ms [memory ] 0.922: Nursery GC 3412K->3092K (33596K), 3.794 ms [memory ] 0.937: Nursery GC 3732K->3412K (33596K), 3.834 ms [memory ] 0.937: Nursery GC 4052K->3732K (33596K), 3.640 ms [memory ] 0.953: Nursery GC 4372K->4052K (33596K), 3.538 ms [memory ] 0.953: Nursery GC 4692K->4372K (33596K), 3.621 ms
`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

memory; gc

with gencopy

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

[memory ] Generational Copying collector [memory ] nursery 640K, to/fromspace 32768K, pinnedspace 4K [memory ] maximal heap 131712-262144K [memory ] <start>: Nursery GC <before>K-><after>K (<heap>K), <total> ms [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 ] 0.828: Nursery GC 298K->212K (33596K), 1.561 ms [memory ] 0.859: Nursery GC 852K->532K (33596K), 3.637 ms [memory ] 0.859: Nursery GC 1172K->852K (33596K), 3.639 ms [memory ] 0.875: Nursery GC 1492K->1172K (33596K), 3.600 ms [memory ] 0.875: Nursery GC 1812K->1492K (33596K), 3.665 ms [memory ] 0.891: Nursery GC 2132K->1812K (33596K), 3.620 ms [memory ] 0.891: Nursery GC 2452K->2132K (33596K), 3.610 ms [memory ] 0.906: Nursery GC 2772K->2452K (33596K), 3.720 ms [memory ] 0.906: Nursery GC 3092K->2772K (33596K), 4.307 ms [memory ] 0.922: Nursery GC 3412K->3092K (33596K), 3.794 ms [memory ] 0.937: Nursery GC 3732K->3412K (33596K), 3.834 ms [memory ] 0.937: Nursery GC 4052K->3732K (33596K), 3.640 ms [memory ] 0.953: Nursery GC 4372K->4052K (33596K), 3.538 ms [memory ] 0.953: Nursery GC 4692K->4372K (33596K), 3.621 ms

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

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

When WebLogic 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 WebLogic JRockit, the JVM does not watch for or process CTRL_LOGOFF_EVENT or SIGHUP events.

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

Ctrl-Break thread dumps are not available.
User code is responsible for causing shutdown hooks to run; for example by calling System.exit() when WebLogic JRockit is to be terminated.

Attaching a Debugger to a Process

You can attach a debugger to a process so that you can see any error messages thrown by that process. To do so, use this procedure:

At the command line, enter the command:

-Djrockit.waitonerror

Note: waitonerror is analogous to Sun's ShowMessageBoxOnError parameter.

When a fatal error occurs, the dumps are produced as usual and a dialog box appears saying "An error occured. Attach the debugger now, then press Yes to debug or No to exit."

At this point, if you want a thread dump, press [Ctrl]-[Break]. Be aware that this might not always work.

Attach the debugger to the process; be sure not to break into the processat this time.

Click Yes in the dialog box to have the debugger to catch the error and break into the process.

If you want better symbol information you should replace the default .pdb file with the private one. You may have problems in getting the debugger to display source code. If this happens, use windbg, as it allows you to set the paths.

Enabling Core Dumps on Linux

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