Skip navigation.
Downloads | Product Documentation | Support

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:

- Before Starting WebLogic JRockit
- Starting WebLogic JRockit
- Configuring WebLogic JRockit
- Attaching a Debugger to a Process
- Enabling Core Dumps on Linux

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\jrockit` `xxx``\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:

- Setting General Information
- Providing Information to the User

- Using Non-standard Options for:

- Setting Behavioral Options
- Displaying Logging Information
- Preventing WebLogic JRockit JVM (When Run as a Service) from Shutting Down After Receiving a Logoff Event

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

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

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

1. At this point, if you want a thread dump, press `[Ctrl]`-`[Break]`. Be aware that this might not always work.
2. Attach the debugger to the process; be sure not to break into the processat this time.

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