jrockit R28参数说明列表2

2 -X Command-Line Options

This chapter is an alphabetically ordered reference for all the -X command-line options that you can use with the JRockit JVM.

The -X command-line options are exclusive to the Oracle JRockit JVM. You can use the -X command-line options to change the behavior of the JRockit JVM to suit the needs of different Java applications. These options do not work on other JVMs (conversely, the nonstandard options used by other JVMs do not work with the JRockit JVM).

Notes:

• The -X options are subject to change at any time.

• Command-line options are case sensitive unless explicitly stated. Most of the commands use the camel notation (for example, -Xgc and -XlargePages).

• If you do not add a unit with the values of options that specify memory size, you get the exact value; for example, 64 is considered as 64 bytes, not 64 megabytes or 64 kilobytes.

-Xbootclasspath
-Xbootclasspath/a
-Xbootclasspath/p
-Xcheck:jni
-Xdebug
-Xgc
-XgcPrio (deprecated)
-XlargePages
-Xmanagement
-Xms
-Xmx
-XnoClassGC (deprecated)
-XnoOpt
-Xns
-XpauseTarget
-Xrs
-Xss
-XstrictFP
-Xverbose
-Xverbosedecorations
-XverboseLog
-XverboseTimeStamp
-Xverify

---

-Xbootclasspath

The -Xbootclasspath option specifies a list of directories, JAR files, and ZIP archives to search for bootstrap classes and resources. These are used in place of the bootstrap class files included in the Java SE JDK.

Note:

Applications that use this option to override a class in the rt.jar file should not be deployed. It violates the Java SE run-time environment binary code license.

Format

-Xbootclasspath directories and zips/jars separated by ; (Windows) or : (Linux and Solaris)

The -Xbootclasspath option name must be entered in lowercase as shown in the preceding format (not in camel notation).

Related Options

• -Xbootclasspath/a

• -Xbootclasspath/p

---

-Xbootclasspath/a

The -Xbootclasspath/a option is similar to -Xbootclasspath in that it specifies a list of directories, JAR files, and ZIP archives; however, the list is appended to the default bootstrap class path.

Format

-Xbootclasspath/a directories and zips/jars separated by ; (Windows) or : (Linux and Solaris)

The -Xbootclasspath/a option name must be entered in lowercase as shown in the preceding format (not in camel notation).

Related Options

• -Xbootclasspath

• -Xbootclasspath/p

---

-Xbootclasspath/p

The -Xbootclasspath/p option is similar to -Xbootclasspath in that it specifies a list of directories, JAR files, and ZIP archives; however, the list is prepended to the default bootstrap class path.

Format

-Xbootclasspath/p directories_and_zips/jars_separated_by ; (Windows) or : (Linux and Solaris)

The -Xbootclasspath/b option name must be entered in lowercase as shown in the preceding format (not in camel notation).

Related Options

• -Xbootclasspath

• -Xbootclasspath/a

---

-Xcheck:jni

The -Xcheck:jni option enables additional checks for JNI functions.

Note:

Oracle recommends that you use -XX:+CheckJNICalls instead of -Xcheck:jni.

---

-Xdebug

The -Xdebug option enables debugging capabilities that are used by the JVM Tools Interface (JVMTI).

Note:

Although -Xdebug works in R28, Oracle recommends that you use -XX:+JavaDebug instead.

For more information about -Xdebug, see the Oracle JRockit R27 documentation at:

http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/jrdocs/refman/optionX.html

Caution:

Do not use the -Xdebug option in the production environment, because, when running with the -Xdebug option, the JVM does not run at full speed.

---

-Xgc

The -Xgc option enables you to specify a garbage collection mode.

You can choose a garbage collector that is either generational or single spaced with a parallel or a concurrent mark and uses either a parallel sweep or a concurrent sweep.

• Generational Garbage Collection

  During a two-generational garbage collection, the heap is divided into two sections: an old generation and a young generation (nursery). Objects are allocated in the nursery and when it is full, the JVM stops all Java threads and moves the live objects from the nursery, young generation, to the old generation.

• Single-spaced Garbage Collection

  The single-spaced option of garbage collection means that all objects live out their lives in a single space on the heap, regardless of their age. In other words, a single-spaced garbage collector does not have a nursery.

• Concurrent Mark and Sweep Algorithm

  The concurrent garbage collection algorithm does its marking and sweeping concurrently with all other processing; that is, it does not stop Java threads to do the complete garbage collection.

• Parallel Garbage Collection Mark and Sweep Algorithm

  The parallel garbage collection algorithm stops Java threads when the heap is full and uses every CPU to perform a complete mark and sweep of the entire heap. A parallel garbage collector can have longer pause times than concurrent garbage collectors, but it maximizes application throughput. Even on single CPU machines, this maximized performance makes parallel the recommended garbage collector, provided that your application can tolerate the longer pause times.

Format

-Xgc:mode

Table 2-1 lists the garbage collection modes that you can specify with the -Xgc option.

Table 2-1 Valid Garbage Collection Modes for -Xgc

Mode	Description
singlecon Alias: singleconcon	Single-space (nongenerational), concurrent garbage collection. In the singlecon garbage collection mode, most of the garbage collection tasks are performed concurrently with the Java application. All objects are maintained in a single space, or generation. The singlecon mode reduces application throughput but keeps pause times to a minimum.
gencon Alias: genconcon	Generational, concurrent garbage collection. In the gencon garbage collection mode, objects are allocated in the young generation (nursery). When the nursery is full, the JRockit JVM stops all the Java threads and moves the live objects in the young generation to the old generation. Most of the old collection tasks are performed concurrently with the Java application. The gencon mode is better than the singlecon mode for most applications that allocate numerous small, short-lived objects. The gencon mode increases heap size and reduces application throughput, but keeps pause times to a minimum.
singlepar Alias: singleparpar, parallel	Single-space, parallel garbage collection. In this mode, when the heap is full, all the Java threads are stopped and the JVM uses every CPU to perform a complete garbage collection of the entire heap. This mode increases pause times when compared with the concurrent mode but maximizes throughput. Even on single CPU systems, the maximized throughput makes parallel garbage collection the recommended mode, provided the application can tolerate the longer pause times.
genpar Alias: genparpar	Generational garbage collection. In the genpar mode, objects are first allocated in the young generation (nursery). When the nursery is full, the JRockit JVM stops all the Java threads and performs a parallel, young collection; that is, it uses all the available CPU resources and moves the live objects in the young generation to the old generation. When the heap is full, the JRockit JVM stops all the Java threads and performs a complete parallel collection. This collector prioritizes throughput over pause times. This mode is generally better than the singlepar mode for applications that allocate numerous short-lived objects. In this mode, a higher number of garbage collections are performed than in the singlepar mode, but the individual pause times are shorter, resulting in lower fragmentation in the old generation space.
genconpar	Generational garbage collection. Sets the garbage collection mode to generational (two-spaced) with a concurrent mark algorithm and a parallel sweep algorithm.
genparcon	Generational garbage collection. Sets the garbage collection mode to generational (two-spaced) with a parallel mark algorithm and a concurrent sweep algorithm.
singleconpar	Single-space garbage collection. Sets the garbage collection mode to single-spaced with a concurrent mark algorithm and a parallel sweep algorithm.
singleparcon	Single-space garbage collection. Sets the garbage collection mode to single-spaced with a parallel mark and a concurrent sweep algorithm.
throughput	The garbage collector is optimized for application throughput. This means that the garbage collector works as effectively as possible, giving as much CPU resources to the Java threads as possible. This might, however, cause nondeterministic pauses when the garbage collector stops all Java threads for garbage collection.The throughput priority should be used when non-deterministic pauses do not impact the application's behavior.
pausetime	The garbage collector is optimized for short pauses. This means that the garbage collection works concurrently with the Java application when necessary, in order to avoid pausing the Java threads. This inflicts a slight performance overhead to the application, as the concurrent garbage collector demands more system resources (CPU time and memory) than the parallel garbage collector that is used for optimal throughput. The target pause time is by default 500 msec. To change the default pause target, see -XpauseTarget.
deterministic	Optimizes the garbage collector for very short and deterministic pause times. The garbage collector tries to keep the garbage collection pauses below a given pause target. The performance depends on the application and the hardware.Running on slower hardware, with a different heap size or with a large amount of active data can break the deterministic behavior or cause performance degradation over time; faster hardware or a less amount of active data might allow you to set a lower pause target.The pause target for deterministic mode is by default 30 msec, and can be changed with the command-line option -XpauseTarget.

Default Value

The default garbage collection mode is the throughput mode.

Related Options

When the -XXsetGC (deprecated) or -XgcPrio (deprecated) options are specified, the -Xgc option is overridden, and vice versa. The option specified first on the command line is ignored.

---

-XgcPrio (deprecated)

The -XgcPrio option is deprecated in Oracle JRockit R28. The option works in R28, but Oracle recommends that you use -Xgc instead. For more information, see -Xgc.

For more information about the format and usage of -XgcPrio, see the R27 documentation at: http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/jrdocs/refman/index.html.

---

-XlargePages

The -XlargePages option specifies to use large pages, if they are available, for the Java heap and other areas in the JVM. Large pages allow your application to more effectively use the translation look-aside buffer (TLB) in the processor.

Note:

Oracle recommends that you use the -XX:+|-UseLargePagesFor[Heap|Code] option for enabling large pages.

Format

-XlargePages:exitOnFailure=true

Windows, Linux, and Solaris support multiple page sizes on x86 and SPARC architectures. x86 supports 4 KB and 4 MB (2 KB and 2 MB in PAE mode). SPARC supports a wider range of different sizes, from 4 KB to 256 MB, depending on the model.

By default, the JVM continues to run without large pages if large pages cannot be acquired when the -XlargePages option is enabled. Use the extended option (-XlargePages:exitOnFailure) to override this behavior and to force the JVM to exit if enough large pages cannot be acquired.

Note:

If you use this option, you must configure large pages on your system by following the procedures specific to your operating system.

For more information about large pages on Linux, read the file vm/hugetlbpage.txt available in the documentation for the Linux kernel.

Nothing has to be configured in the Solaris operating system to enable an application to use large pages.

If the JRockit JVM fails to acquire large pages, it prints a warning as shown in the following example and continues to work:

[ERROR][osal ] Unable to set Lock Page Privilege:
...
[WARN ][memory ] Could not acquire large pages for Java heap.
[WARN ][memory ] Falling back to normal page size.

Default

-XlargePages is disabled by default on Windows and Linux platforms. On Solaris SPARC, this option is enabled by default.

---

-Xmanagement

The -Xmanagement option starts the JRockit JVM concurrently with the management server and allows you to either enable and configure or explicitly disable features such as autodiscovery of the JVM instances in a network, SSL encryption, and authentication.

Format

-Xmanagement[:parameter1=value[,parameter2=value2]]

Table 2-6 lists the possible values for parametern=valuen pairs.

Table 2-2 -Xmanagement Parameters

Parameter	Description	Default Value
None	Enables the JMX local monitoring through a JMX connector published on a private interface used by local JMX clients that use the Attach API. JMX clients can use this connector if it is started by the same user who started the agent. No password or access files are required for requests coming through this connector.	true
autodiscovery=true|false	Enables or disables autodiscovery for the remote JMX connector, which allows Oracle JRockit Mission Control to automatically discover running JRockit JVM instances through the multicast-based JRockit Discovery Protocol (JDP). The autodiscovery enables other machines on the same subnet to automatically detect a remote management-enabled JVM. Note: The JVM Browser in Oracle JRockit Mission Control automatically discovers remote JVM instances only if this option is enabled. Related -D option: -Dcom.oracle.management.autodiscovery	false
autodiscovery_name=/mycluster/mymachine/Node1	Enables you to specify the path and name of the cluster and node from where Oracle JRockit Mission Control discover information about various JRockit JVM instances running in a network. Note: You can use this option only when autodiscovery is set to true.	-
authenticate=true|false	Enables or disables authentication. When this property is set to false, JMX does not use passwords or access files. All users are allowed all access. Related -D option: -Dcom.oracle.management.jmxremote.authenticate	true
class=class_name	Loads the class and causes its empty constructor to be called early in JVM startup. From the constructor, a new thread is then started, from which your management client is run. Further arguments cannot be given to -Xmanagement after the class argument.	-
config_file=path	Specifies the location of the file from which additional management configuration properties are loaded. Related -D option: -Dcom.oracle.management.config.file	JRE_HOME/lib/management/management.properties
interface=host|ip	Specifies the IP address or the host name of the remote machine. If this option is set, only then connections to a specified ip (or host) are allowed. The JMX agent still listens to and answer connections on all interfaces; however, connections to other addresses than those specified by this option are discarded. Related -D option: -Dcom.oracle.management.jmxremote.interface	null
local=true|false	Enables or disables the local JMX connector. Related -D option: -Dcom.oracle.management.jmxremote	true
port=portNumber	Identifies the port that the management server opens for remote access. When you specify a port number, the JMX remote agent is enabled and it creates a remote JMX connector to listen through the specified port. By default, the SSL, password, and access file properties are used for this connector. This option also enables local monitoring. Related -D option: -Dcom.oracle.management.jmxremote.port	7091, when you do not specify a value for this option.
registry_ssl=true|false	Binds the RMI connector stub to an RMI registry protected by SSL. Related -D option: -Dcom.oracle.management.jmxremote.registry.ssl	false
remote=true|false	Enables or disables the remote JMX connector.	false
rmiserver_port=portNumber	Binds the RMI Server to the specified port. Related -D option: -Dcom.oracle.management.jmxremote.rmiserver.port	Bind to the same port as the RMI Registry. If the RMI Server is using SSL and the registry is not, a random port is selected.
ssl=true|false	Enables or disables SSL encryption.	true

Examples

java -Xmanagement:ssl=false,authenticate=false myApplication

Disables SSL encryption and authentication.

java -Xmanagement:autodiscovery=true myApplication

Enables autodiscovery.

java -Xmanagagement:autodiscovery=true,autodiscovery_name=/mycluster/mymachine/Node1

The JRockit JVM appears under the JDP/mycluster/mymachine folder with the connection name as Node1. If you specify a forward slash (/) at the end of the path, the name of the resulting descriptor is determined by a reverse DNS lookup.

java -Xmanagagement:port=1234 myApplication

Directs the management server to open port 1234.

Due to the security risks and the mission-critical nature of most JRockit JVM deployments, the new default behavior of the JRockit JVM requires that you either disable security explicitly or configure and enable security. If you do not take these steps, the management server does not open a port for remote access and might cause the JVM startup to halt with an error message concerning the security configuration.

Specifying the -Xmanagement option also enables a local in-memory agent to improve the user experience from a developer perspective. For example, a developer running a WebLogic Server instance on JRockit JVM on a machine can specify the -Xmanagement option to enable the local in-memory agent to connect to it from an Oracle JRockit Mission Control Client on another machine. On the other hand, the developer would not have to specify the -Xmanagement option to get local access from Oracle JRockit Mission Control: the in-memory agent is always accessible locally. If you have a number of JRockit JVM instances running on your machine and you start a JRockit Mission Control Client, it automatically discovers and allows access to those JVMs. Security is enforced by allowing this type of local access only if the JRockit JVM instance and the JRockit Mission Control Client are being run by the same user.

To enable the management agent without security you must now specify that SSL and authentication should be disabled.

For maximum usability, enable the autodiscovery mechanism, which allows JRockit Mission Control to automatically discover the running JRockit JVM instances through the multicast-based JRockit Discovery Protocol. Note that this typically works only on the local subnet.

Default Values

The default behavior is as follows:

• Local agent is enabled.

• Remote management agent is enabled with security, if SSL encryption, authentication, and networking are configured. If SSL and authentication are not configured, remote management agent is enabled with security explicitly disabled.

---

-Xms

The -Xms option sets the initial and minimum Java heap size. The Java heap (the heap) is the part of the memory where blocks of memory are allocated to objects and freed during garbage collection.

Note:

The -Xms option does not limit the total amount of memory that the JVM can use.

Format

-Xms:size[g|G|m|M|k|K]

Combine -Xms with a memory value and add a unit.

Example

java -Xms:64m myApp

This command sets the initial and minimum java heap to 64 MB.

If you do not add a unit, you get the exact value; for example, 64 is interpreted as 64 bytes, not 64 megabytes or 64 kilobytes.

For good performance, set the -Xms option to the same size as the maximum heap size, for example:

java -Xmx:64m -Xms:64m myApp

Default Values

If you do not set this option, the minimum Java heap size defaults to the following (depending on which mode you are running):

• -server mode: 25% of the amount of free physical memory in the system, up to 64 MB and at least 8 MB.

• -client mode: 25% of the amount of free physical memory in the system, up to 16 MB and at least 8 MB.

• If the nursery size is set with the -Xns option, the default initial heap size is scaled up to at least twice the nursery size.

Exceptions and Recommendations

The initial Java heap cannot be set to a smaller value than 8 MB, which is the minimum Java heap size. If you set this option to a smaller value than 8 MB, JRockit JVM prints an error message and terminates.

The -Xms value cannot exceed the value set for -Xmx (the maximum Java heap size).

---

-Xmx

The -Xmx option sets the maximum Java heap size. The Java heap is the part of the memory where blocks of memory are allocated to objects and freed during garbage collection. Depending upon the kind of operating system you are running, the maximum value you can set for the Java heap can vary.

Note:

The -Xmx option does not limit the total amount of memory that the JVM can use.

Format

-Xmx:size[g|G|m|M|k|K]

Combine the -Xmx option with a memory value.

Example

java -Xmx:1g myApp

This command sets the maximum Java heap to 1 Gigabyte.

If you do not add a unit, you get the exact value; for example, 64 is interpreted as 64 bytes, not 64 megabytes or 64 kilobytes.

The -Xmx and -Xms options, in combination, are used to limit the Java heap size. The Java heap can never grow larger than -Xmx. The -Xms value can also be used as the minimum heap size to set a fixed heap size by setting -Xms = -Xmx when, for example, you want to run benchmark tests.

Default Values

If you do not set this option, the maximum Java heap size depends on the platform and the amount of memory in the system as described in Table 2-3.

Table 2-3 Default Maximum Heap Sizes

Platform	Default Maximum Heap Size
Windows on a 64 bit platform	75% of total physical memory up to 3 GB
Linux or Solaris on a 64 bit platform	75% of physical memory up to 3 GB
Windows on a 32 bit platform	75% of total physical memory up to 1 GB
Linux or Solaris on a 32 bit platform	75% of physical memory up to 1 GB

Exceptions

When using -Xmx, be aware of the following exceptions:

• If both -Xmx and -Xms are specified the value of -Xmx must be larger than or equal to that of -Xms.

• If both -Xmx and -Xns are specified the value of -Xmx must be larger than or equal to that of -Xns.

• The minimum value for -Xmx is 16 MB.

---

-XnoClassGC (deprecated)

The -XnoClassGC option is deprecated in Oracle JRockit R28. The option works in R28, but Oracle recommends that you use -XX:-UseClassGC instead. For more information, see -XX:+|-UseClassGC.

For more information about the format and usage of -XnoClassGC, see the R27 documentation at: http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/jrdocs/refman/index.html.

---

-XnoOpt

The -XnoOpt option turns off adaptive optimization.

Optimized code generally runs faster than code that has not been optimized, but occasionally, the time required to optimize code results in undesirable delays in processing. -XnoOpt avoids these delays by turning off optimization. This option is also helpful when you suspect that a JVM or application problem, such as a system crash or poor startup performance, might be related to optimization. You can turn optimization off and retry your application. If it then runs successfully, you can safely assume that the problem lies with code optimization.

If -XnoOpt is not set, the JVM optimizes code as usual.

Format

-XnoOpt

---

-Xns

The -Xns option sets the nursery size. The JRockit JVM uses a nursery when a generational garbage collector is being used.

Format

-Xns:size[g|G|m|M|k|K]

Combine -Xns with a memory value.

The nursery size value cannot exceed the maximum value set for the heap.

Example

java -Xns:10m myApp

Sets the nursery to 10 MB of the heap.

Default Value

The default value depends on the garbage collection mode, as described in Table 2-4.

Table 2-4 Default Nursery Sizes

Options used	Default value
-server (default)	50% of free heap
-client	None; nursery does not exist
-Xgc:gencon, -Xgc:pausetime	10 MB per logical processor (maximum 80 MB)
-Xgc:genpar, -Xgc:throughput	50% of free heap

Exceptions

The -Xns option is valid only when a generational garbage collector is used.

---

-XpauseTarget

The -XpauseTarget option sets a pause target for the garbage collection mode optimizing for short pauses (-Xgc:pausetime) and the garbage collection mode optimizing for deterministic pauses (-Xgc:deterministic). The target value is used as a pause time goal. The target helps the garbage collector to more precisely configure itself to keep pauses near the target value. Using this option allows you to specify the pause target to be between 1 millisecond and 5 seconds. If you are using the deterministic garbage collector, you can set values below 200 milliseconds.

Format

-XpauseTarget=value

The value set by this option is considered a soft goal; that is, if specifying the target to 100 msec, the garbage collector tries to tune itself towards a configuration that makes the pauses become as near 100 msec as possible. However, if you have an application and heap configuration that does not meet this target even after the garbage collector is tuned, the target is missed. This option specifies only the desired pause times, not the maximum allowed pause time.

When you use this option properly, it improves pause times. Otherwise, it might stress the garbage collector and affect performance.

Default Values

If you are using -XpauseTarget with -Xgc:pausetime, the default setting for the target is 500 msec. If you are using -Xgc:deterministic, the default value is 30 msec.

Related Options

Normally, this option requires that you use it with a pause optimizing garbage collection mode (-Xgc:pausetime or -Xgc:deterministic). If you do not specify a garbage collector, this option changes from the default garbage collector to the pause time optimizing garbage collector (the same collector used when specifying -Xgc:pausetime).

If you are using Oracle JRockit Real Time, set -XgcPauseTarget less than 200 msec, and do not specify a garbage collector. The garbage collector is set to -Xgc:deterministic.

Exceptions

When using -XpauseTarget, note the following exceptions:

• Setting -XpauseTarget has not effect if you are running the garbage collector in throughput mode.

• If you are using the deterministic garbage collector, you can specify pause targets below 200 msec as well.

---

-Xrs

Note:

-Xrs is a non-standard option in HotSpot JVM. JRockit JVM continues to support this option; however, the JRockit JVM nonstandard options -Xnohup and -XX:+|-ReduceSignalUsage provide the same functionality.

-Xrs reduces usage of operating-system signals by the JVM. If the JVM is run as a service (for example, the servlet engine for a web server), it can receive CTRL_LOGOFF_EVENT but should not initiate shutdown since the operating system does not actually terminate the process. To avoid possible interference such as this, the -Xrs command-line option does not install a console control handler, implying that it does not watch for or process CTRL_C_EVENT, CTRL_CLOSE_EVENT, CTRL_LOGOFF_EVENT, or CTRL_SHUTDOWN_EVENT.

Format

-Xrs

If you are running JRockit JVM as a service (for example, the servlet engine for a web server), enter the command at startup to prevent the JVM from watching for or processing CTRL_LOGOFF_EVENT or SIGHUP events.

Exceptions

The following are exceptions when you use this option:

• Pressing Ctrl-Break to create a thread dump does not work.

• User code is responsible for causing shutdown hooks to run.

---

-Xss

The -Xss option sets the thread stack size. Thread stacks are memory areas allocated for each Java thread for their internal use. This is where the thread stores its local execution state.

Format

-Xss:size[g|G|m|M|k|K]

Combine -Xss with a memory value.

Note:

JRockit does not support stack sizes above 128 MB.

Example

java -Xss:512k myApp

Sets the default stack size to 512 kilobytes.

Default Values

-Xss default values are specific to the JVM binary, as defined in Table 2-5.

Table 2-5 -Xss Default Values

Platform	Default
Windows IA32	64 KB
Windows x86_64	128 KB
Linux IA32	128 KB
Linux x86_64	256 KB
Solaris SPARC	512 KB

---

-XstrictFP

Oracle recommends that you use -XX:+StrictFP instead of -XstrictFP.

For more information about -XstrictFP, see the R27 documentation at http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/jrdocs/refman/index.html.

---

-Xverbose

The -Xverbose option provides specific information about the system. The output is, by default, printed to the standard output for error messages (stderr) but you can redirect it to a file by using the -XverboseLog command-line option. The information displayed depends on 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 hyperthreading is enabled.

Format

-Xverbose:parameter[=log_level]

Table 2-6 lists the parameters, and Table 2-7 lists the log levels.

Note:

To use more than one parameter, separate them with a comma (for example, -Xverbose:gc,opt).

Table 2-6 -Xverbose Parameters

Parameter	Prints to the screen
alloc	Information regarding allocations and out of memory.
class	The names of classes loaded; sample output might look like this: [INFO ][class ] created: # 0 java/lang/Object (c:\jrockits\R28.0.0_R28.0.0-617_1.6.0\jre\lib\rt.jar) [INFO ][class ] 0 java/lang/Object success (0.60 ms) [INFO ][class ] created: # 2 java/io/Serializable (c:\jrockits\R28.0.0_R28.0.0-617_1.6.0\jre\lib\rt.jar) [INFO ][class ] 2 java/io/Serializable success (0.32 ms)
codegen	The names of each method that is being compiled. Verbose output for codegen might look like this: [INFO ][codegen][00004] #240 (Normal) java/lang/AbstractStringBuilder.<init>(I)V [INFO ][codegen][00004] #240 0.315-0.316 0x0000000100019FA0-0x0000000100019FD2 0.38 ms 128KB 31618 bc/s (138.48 ms 60442 bc/s) [INFO ][codegen][00004] #241 (Normal) java/lang/StringBuilder.append(Ljava/lang/String;)Ljava/lang/StringBuilder; [INFO ][codegen][00004] #241 0.316-0.316 0x0000000100019FE0-0x0000000100019FF5 0.37 ms 128KB 21503 bc/s (138.85 ms 60338 bc/s) [INFO ][codegen][00004] #242 (Normal) java/lang/AbstractStringBuilder.append(Ljava/lang/String;)Ljava/lang/AbstractStringBuilder; [INFO ][codegen][00004] #242 0.317-0.317 0x000000010001A000-0x000000010001A07E 0.53 ms 128KB 113605 bc/s (139.38 ms 60539 bc/s) [INFO ][codegen][00004] #243 (Normal) java/lang/StringBuilder.append(C)Ljava/lang/StringBuilder; [INFO ][codegen][00004] #243 0.318-0.318 0x000000010001A080-0x000000010001A09C 0.37 ms 128KB 21747 bc/s (139.75 ms 60437 bc/s)
compaction	Information related to the compaction. This information varies for different garbage collection types and also depends on the result of the compaction. Verbose output for compaction might look like this: [INFO ][compact] [OC#2] Compacting 8 of 128 parts at index 0. Compaction type is internal. Exceptional: No. [INFO ][compact] [OC#2] Compaction area start: 0x2043000, end: 0x263a800.Timeout: 100.000 ms. [INFO ][compact] [OC#2] Compactset limit (per thread): 37487 (dynamic), not using matrixes. [INFO ][compact] [OC#2] Adjusted compaction area to start at 0x2043000 and end at 0x263a8d8. [DEBUG][compact] [OC#2] Internal compaction added 0x25f24f8 - 0x263a8d8 to the freelist, size: 289KB. [INFO ][compact] [OC#2] Internal compaction found 5698 objects and moved 5681 objects. [INFO ][compact] [OC#2] Compaction overhead increased to: 3.000. [INFO ][compact] [OC#2] Compaction pause: 3.677 ms (target 50.000 ms), update ref pause: 119.897 ms (target 50.000 ms). [INFO ][compact] [OC#2] Updated 518 references. Internal: 6125 External: 518. [DEBUG][compact] [OC#2] Compaction ended at index 5, object end address was 0x263a8d8. [INFO ][compact] [OC#2] Average compact time ratio: 0.022901. [INFO ][compact] [OC#2] Too few references, doubling compact ratio.
cpuinfo	Technical information about your CPUs. Verbose output for cpuinfo might look like this: [INFO ][cpuinfo] HT is: not supported by the CPU, not enabled by the OS, not enabled in JRockit. [INFO ][cpuinfo] CPU: Intel Pentium M model D SSE SSE2 [INFO ][cpuinfo] Vendor: GenuineIntel [INFO ][cpuinfo] Family: Pentium M model D [INFO ][cpuinfo] Model: Pentium M model D [INFO ][cpuinfo] Name: Intel(R) Pentium(R) M processor 2.00GHz [INFO ][cpuinfo] Sockets: 1 [INFO ][cpuinfo] Cores: 1 [INFO ][cpuinfo] HWThreads: 1 [INFO ][cpuinfo] Supports: On-Chip FPU [INFO ][cpuinfo] Supports: Virtual Mode Extensions [INFO ][cpuinfo] Supports: Debugging Extensions [INFO ][cpuinfo] Supports: Page Size Extensions [INFO ][cpuinfo] Supports: Time Stamp Counter [INFO ][cpuinfo] Supports: Model Specific Registers [INFO ][cpuinfo] Supports: Machine Check Exceptions [INFO ][cpuinfo] Supports: CMPXCHG8B Instruction [INFO ][cpuinfo] Supports: Fast System Call [INFO ][cpuinfo] Supports: Memory Type Range Registers [INFO ][cpuinfo] Supports: Page Global Enable [INFO ][cpuinfo] Supports: Machine Check Architecture [INFO ][cpuinfo] Supports: Conditional Mov Instruction [INFO ][cpuinfo] Supports: Page Attribute Table [INFO ][cpuinfo] Supports: the CLFLUSH Instruction [INFO ][cpuinfo] Supports: the Debug Trace Store feature [INFO ][cpuinfo] Supports: ACPI registers in MSR space [INFO ][cpuinfo] Supports: Intel Architecture MMX Technology [INFO ][cpuinfo] Supports: Fast Float Point Save and Restore [INFO ][cpuinfo] Supports: Streaming SIMD extensions [INFO ][cpuinfo] Supports: Streaming SIMD extensions 2 [INFO ][cpuinfo] Supports: Self-Snoop [INFO ][cpuinfo] Supports: Thermal Monitor
exceptions	Displays exception types and messages (excluding the common types of exceptions). Verbose output for exceptions might look like this: [excepti][00002] java/lang/NumberFormatException: null
exceptions=debug	Displays exception types and messages (excluding the common types of exceptions). It also displays stacktraces; Verbose output for exceptions=debug might look like this: [excepti][00002] java/lang/NumberFormatException: null at java/lang/Integer.parseInt(Ljava/lang/String;I)I(Integer. java:415) at java/lang/Integer.<init>(Ljava/lang/String;)V(Integer. java:620) at sun/net/InetAddressCachePolicy.<clinit>()V (InetAddressCachePolicy.java:77) at jrockit/vm/RNI.c2java(IIII)V(Native Method) at jrockit/vm/RNI.generateFixedCode(I)I(Native Method) at java/net/InetAddress.<clinit>()V(InetAddress.java:640) at jrockit/vm/RNI.c2java(IIII)V(Native Method) at jrockit/vm/RNI.generateFixedCode(I)I(Native Method) at java/net/InetSocketAddress.<init>(Ljava/lang/String;I)V (InetSocketAddress.java:124) at java/net/Socket.<init>(Ljava/lang/String;I)V (Socket.java:178) at Ex.main([Ljava/lang/String;)V(Ex.java:5) at jrockit/vm/RNI.c2java(IIII)V(Native Method) --- End of stack trace
exceptions=trace	The same information as debug, but includes the common types of exceptions. Verbose output for exceptions=trace looks the same as -Xverbose:exceptions=debug but also prints exceptions of types: java.util.EmptyStackException java.lang.ClassNotFoundException java.security.PrivilegedActionException
gc	Displays information about the memory system in the following format: [INFO][memory ] <start>-<end>: <type> <before>KB-><after>KB (<heap>KB), <time> ms, sum of pauses <pause> ms. [INFO][memory ] <start> - start time of collection (seconds since jvm start). [INFO][memory ] <type> - OC (old collection) or YC (young collection). [INFO][memory ] <end> - end time of collection (seconds since jvm start). [INFO][memory ] <before> - memory used by objects before collection (KB). [INFO][memory ] <after> - memory used by objects after collection (KB). [INFO][memory ] <heap> - size of heap after collection (KB). [INFO][memory ] <time> - total time of collection (milliseconds). [INFO][memory ] <pause> - total sum of pauses during collection (milliseconds). For example: [INFO][memory] [YC#1] 0.749-0.992: YC 32768KB->32770KB (65536KB), 0.242 s, sum of pauses 242.279 ms, longest pause 242.279 ms. [INFO][memory] [YC#2] 1.029-1.221: YC 57344KB->65536KB (65536KB), 0.191 s, sum of pauses 191.391 ms, longest pause 191.391 ms. [INFO][memory] [OC#1] 1.221-1.305: OC 65536KB->57169KB (102512KB), 0.085 s, sum of pauses 83.469 ms, longest pause 83.469 ms. [INFO][memory] [YC#3] 1.334-1.343: YC 65118KB->60949KB (102512KB), 0.009 s, sum of pauses 8.534 ms, longest pause 8.534 ms.
gcheuristic	Information about the decisions that the garbage collection heuristics make and also the heap size changes.
gcpause	Prints the pause times caused by the garbage collector during a run. The pause times are shown during run time on your screen during the running of the application. Use this option at startup. As pauses are encountered, a report is printed. Output from -Xverbose:gcpause used with -Xgc:gencon: [INFO ][gcpause] [YC#92] [---] 4.145 ms (26.121000-26.125000) YC [INFO ][gcpause] [YC#92] [con] 0.003 ms (26.121000-26.121000) YC:PreGC [INFO ][gcpause] [YC#92] [pau] 4.095 ms (26.121000-26.125000) YC:Main [INFO ][gcpause] [YC#92] [con] 0.008 ms (26.125000-26.125000) YC:PostGC [INFO ][gcpause] [YC#93] [---] 4.710 ms (26.352000-26.356000) YC [INFO ][gcpause] [YC#93] [con] 0.002 ms (26.352000-26.352000) YC:PreGC [INFO ][gcpause] [YC#93] [pau] 4.644 ms (26.352000-26.356000) YC:Main [INFO ][gcpause] [YC#93] [con] 0.009 ms (26.356000-26.356000) YC:PostGC [INFO ][gcpause] [OC#1] [---] 63.312 ms (26.362000-26.425000) OC [INFO ][gcpause] [OC#1] [con] 0.006 ms (26.362000-26.362000) OC:PreGC [INFO ][gcpause] [OC#1] [pau] 4.979 ms (26.362000-26.367000) OC:Initial [INFO ][gcpause] [OC#1] [con] 50.462 ms (26.367000-26.417000) OC:ConcurrentMark [INFO ][gcpause] [OC#1] [pau] 4.427 ms (26.417000-26.422000) OC:Main [INFO ][gcpause] [OC#1] [con] 0.829 ms (26.422000-26.422000) OC:ConcurrentSweep1 [INFO ][gcpause] [OC#1] [pau] 0.011 ms (26.422000-26.422000) OC:SweepSwitch [INFO ][gcpause] [OC#1] [con] 1.137 ms (26.422000-26.424000) OC:ConcurrentSweep2 [INFO ][gcpause] [OC#1] [pau] 0.224 ms (26.424000-26.424000) OC:Cleanup [INFO ][gcpause] [OC#1] [con] 0.982 ms (26.424000-26.425000) OC:PostGC [INFO ][gcpause] [YC#94] [---] 4.738 ms (26.720000-26.725000) YC [INFO ][gcpause] [YC#94] [con] 0.003 ms (26.720000-26.720000) YC:PreGC [INFO ][gcpause] [YC#94] [pau] 4.692 ms (26.720000-26.725000) YC:Main [INFO ][gcpause] [YC#94] [con] 0.007 ms (26.725000-26.725000) YC:PostGC
gcpausetree	Prints the same information as gcpause, but with indentation instead of full level information, therefore makes the output more readable. But this output is less parsable.
gcreport	Generates a report that shows garbage collection statistics for your application. You can use this report to determine if you are using the most effective garbage collector. The report divides the statistics into young collections and old collections, and for each type the following information gathered during the run time is displayed Number of collections: The total number of garbage collections of this type. Total promoted: The total number of objects and bytes promoted from young space to old space by this type of garbage collections. Max promoted: The maximum number of objects and bytes promoted by any single garbage collection of this type. Total GC time: The total time spent in this type of garbage collections. For concurrent garbage collections, the total garbage collection time and the total garbage collection pause time differs. Mean GC time: The average time spent in a single garbage collection of this type. For concurrent garbage collections, the garbage collection time and the garbage collection pause time differs. Maximum GC pauses: The three longest garbage collection pauses caused by this type of garbage collection. Output from -Xverbose:gcreport used with -Xgcprio:pausetime: [INFO ][gcrepor] [INFO ][gcrepor] Memory usage report: [INFO ][gcrepor] [INFO ][gcrepor] Young Collections: [INFO ][gcrepor] number of collections = 1674. [INFO ][gcrepor] total promoted = 125334074 (size 4556008384). [INFO ][gcrepor] max promoted = 672140 (size 29971808). [INFO ][gcrepor] total YC time = 12.959 s (total paused 12.810 s). [INFO ][gcrepor] mean YC time = 7.741 ms (mean total paused 7.652 ms). [INFO ][gcrepor] maximum YC Pauses = 38.941 , 40.473, 63.004 ms. [INFO ][gcrepor] [INFO ][gcrepor] Old Collections: [INFO ][gcrepor] number of collections = 828. [INFO ][gcrepor] total promoted = 37563437 (size 1393626896). [INFO ][gcrepor] max promoted = 328350 (size 14209984). [INFO ][gcrepor] total OC time = 349.090 s (total paused 83.380 s). [INFO ][gcrepor] mean OC time = 421.606 ms (mean total paused 100.701 ms). [INFO ][gcrepor] maximum OC Pauses = 445.945 , 446.394, 3096.186 ms. [INFO ][gcrepor] [INFO ][gcrepor] number of emergency parallel sweeps = 361. [INFO ][gcrepor] [INFO ][gcrepor] number of internal compactions = 582. [INFO ][gcrepor] number of internal compactions skipped because pointer storage overflowed = 8. [INFO ][gcrepor] number of external compactions = 234. [INFO ][gcrepor] 177 of these were aborted because they timed out. [INFO ][gcrepor] number of external compactions skipped because pointer storage overflowed = 4. [INFO ][gcrepor]
load	The name of each loaded Java or native library: [INFO ][load ] opened zip c:\jrockits\R28.0.0_R28.0.0-617_1.6.0\jre\lib\rt.jar [INFO ][load ] opened zip c:\jrockits\R28.0.0_R28.0.0-617_1.6.0\jre\lib\resources.jar [INFO ][load ] opened zip c:\jrockits\R28.0.0_R28.0.0-617_1.6.0\jre\lib\jsse.jar [INFO ][load ] opened zip c:\jrockits\R28.0.0_R28.0.0-617_1.6.0\jre\lib\jce.jar [INFO ][load ] opened zip c:\jrockits\R28.0.0_R28.0.0-617_1.6.0\jre\lib\charsets.jar
memory	Prints 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 printed by -Xverbose:memory varies depending on the type of garbage collector you are using.
memdbg	Enables debug level for verbose modules that are useful when you debug memory-related issues. Verbose output for memdbg might look like this: [DEBUG][memory ] [YC#3526] GC reason: Allocation request failed. [DEBUG][memory ] [YC#3526] 455.018: YC started. [INFO ][alloc ] [YC#3526] Pending requests at 'Before YC' - Total: 8, TLAs: 8 (approx 262144 bytes), objects: 0 (0 bytes). Max age: 0. [INFO ][nursery] [YC#3526] Young collection 3526 started. This YC is running while the OC is in phase: not running. [DEBUG][memory ] [YC#3526] Promotion failed: not enough free memory for java/lang/String, 32 B. [DEBUG][memory ] [YC#3526] Returning duplicate cardTablePart entry 2895 (0x00000000155EDE00-0x000000001562DE00) [DEBUG][memory ] [YC#3526] Returning duplicate cardTablePart entry 2895 (0x00000000155EDE00-0x000000001562DE00) [DEBUG][memory ] [YC#3526] SemiRef phase Finalizers run in single threaded mode. [DEBUG][memory ] [YC#3526] SemiRef phase WeakJNIHandles run in single threaded mode. [DEBUG][memory ] [YC#3526] SemiRef phase ClassConstraints run in single threaded mode. [INFO ][nursery] [YC#3526] Setting forbidden area for keeparea: 0x00000000133479A0-0x000000001386DE20. [INFO ][nursery] [YC#3526] Next keeparea will start at 0x0000000012F34E48 and end at 0x00000000133479A0. [INFO ][alloc ] [YC#3526] Pending requests at 'After YC' - Total: 8, TLAs: 8 (approx 262144 bytes), objects: 0 (0 bytes). Max age: 0. [DEBUG][memory ] [YC#3526] YC promoted 10964 objects (384KB). [DEBUG][memory ] [YC#3526] Page faults before YC: 283554, page faults after YC: 283554, pages in heap: 65536. [DEBUG][memory ] [YC#3526] Nursery size after YC: 0KB. (Free: 0KB Parts: 0) [INFO ][memory ] [YC#3526] 455.018-455.033: YC 261708KB->262144KB (262144KB), 0.015 s, sum of pauses 14.090 ms, longest pause 14.090 ms.
opt	Information about all methods that get optimized. Verbose output for opt might look like this: [INFO ][opt ][00036] #1 (Opt) ObjAlloc.main([Ljava/lang/String;)V [INFO ][opt ][00036] #1 3.756-3.758 0x0000000100060000-0x000000010006004E 2.10 ms 128KB 7633 bc/s (2.10 ms 7633 bc/s)
refobj	Information on reference objects and handles at each garbage collection. The output is a summary of reference objects of different types and how many of them are activated. A reference object is activated when the requirements for the reference object type are fulfilled. Upon activation, the memory management system can clear the reference, enqueue it in a reference queue or enqueue it for finalization, depending on the type of reference. The performance overhead of this log module is low on info level. On debug level, the performance overhead is high.
starttime	The values of System.currentTimeMillis() and System.nanoTime() at the time JRockit JVM started. These can be used to correlate log output between different processes. Verbose output for starttime might look like this: [INFO ][startti] VM start time: 1260962573921 millis 6922526 nanos 18442244770397334 ticks Where: millis is the number of milliseconds elapsed since midnight, January 1, 1970 UTC. This is same value that System.currentTimeMills() would render. nanos measures time to the resolution of one-billionth of a second (a nanosecond); however, the time from which nanoTime() is measured (the start time) is unspecified so that the most efficient method of measurement for different operating systems can be used. It is the same value that System.nanoTime() would render.
systemgc	Notifies of garbage collections started by a call to System.gc() and -Xverbose:memdbg outputs, for example a call to a JMAPI function that implicitly starts a garbage collection or to the diagnostics command runsystemgc. A garbage collection started by a direct call to System.gc() results in a verbose output similar to: [INFO ][sysgc ] GC requested by thread 1 The thread number in this output is the thread ID of the thread that requests the garbage collection. The output for a garbage collection started by other means display the reason for the garbage collection, for example: [INFO ][sysgc ] GC triggered for reason: Set Nursery Size
timing	The timer resolution and the method used to get a time value. This is the resolution of the timer used by the System.nanoTime() method. The following output is an example of a verbose timing report on Windows: [INFO ][timing ] Fast time frequency is 1995000000hz [INFO ][timing ] Drift is 0.00000021 = per day 0.018secs (max 300.000) [INFO ][timing ] Hardware fast time enabled [INFO ][timing ] Counter timer using resolution of 1995MHz

Table 2-7 -Xverbose Log Levels

Log Level	Description
quiet	No logging. No messages or errors are generated.
error	Only error messages are logged.
warn	Warning messages are logged along with errors. Still a low logging level, warn is usually used to warn about events that could possibly lead to an error later on.
info	At the info level, not only are errors and warnings logged, but also informational messages about the current state of JRockit JVM and various JVM events. This is the default logging level if -Xverbose is used without arguments.
debug	debug logs messages with detailed information of JRockit JVM's behavior. Usually, debug provides too much information for day to day logging, but useful for debugging.
trace	trace provides very verbose logging. This level is used by modules where even the debug level would be cluttered by the amount of information generated. Typically, trace is used when up to ten or one hundred pages of text per minute needs to be logged.

Example

java -Xverbose:gcpause=debug myClass

Enables pause time sampling and information during a run and logs messages with detailed information of the JRockit JVM.

Related Options

-Xverbose must be set for the following options to work:

• -Xverbosedecorations

• -XverboseLog

• -XverboseTimeStamp

---

-Xverbosedecorations

Decorations are additional information, usually system-related, that are used to enhance the meaningfulness of verbose output; for example, the name of the module in which the message originated or number of milliseconds elapsed since the current JRockit JVM session started. The -Xverbosedecorations option adds this information to the verbose output.

Format

-Xverbosedecorations=decoration names

Note:

You can also use the diagnostic command verbosity with the argument decorations.

Table 2-8 lists the possible decorations.

Table 2-8 Verbose Output Decorations

Decoration	Description
level	Prints the logging level for the message.
millis	Prints the number of milliseconds elapsed since midnight, January 1, 1970 UTC. This is same value that would be generated by System.currentTimeMills().
millisstart	Prints the number of milliseconds elapsed since JRockit JVM started.
module	Prints the module in which the message originated, same as the arguments to -Xverbose.
nanos	Prints the same value that System.nanoTime() would render. "nanoTime" measures time to the resolution of one-billionth of a second (a nanosecond); however, the time from which nanoTime() is measured (the start time) is unspecified so that the most efficient method of measurement for different operating systems can be used.
nanosstart	Prints the number of nanoseconds since JRockit JVM started.
pid	Prints the process ID.
threadid	Prints the index of the thread. This is the same value provided by idx in thread dumps.
timestamp	Prints a human readable timestamp. This is the same value you would receive if you used the -XverboseTimeStamp option.

Example

java -Xverbose:gcpause -Xverbosedecorations=timestamp,module myApp

The output includes the following decorations:

• A readable timestamp.

• The name of the module in which the message originated.

Default Values

If you use -XverboseDecorations without specifying a decoration, the verbose output displays the module, timestamp, and pid (in that order); for example:

D:\jrockits\R28.0.0-617_1.6.0\bin>java -Xverbose:load -Xverbosedecorations -cp L:\src\ HelloWorld
[load   ][Wed Sep 13 19:43:14 2006][00728] opened zip D:\jrockits\R28.0.0-617_1.6.0\jre\lib\rt.jar

Related Options

-Xverbosedecorations can be used only if -Xverbose is also set.

---

-XverboseLog

The -XverboseLog option sends messages (such as verbose output and error messages) from the Oracle JRockit JVM to the specified file instead of stderr.

Format

-Xverboselog:myFile.txt

When this command is used with a filename and extension (for example, myFile.txt), the JVM writes any logging information to the specified file.

Example

java -Xverbose:gcpause -Xverboselog:verboseText.txt myApp

Writes verbose logging information for the application with the main class myApp to a file named verboseText.txt.

Related Options

The -XverboseLog option works only when -Xverbose is set.

Exceptions

The -XverboseLog option does not print to the screen.

---

-XverboseTimeStamp

The -XverboseTimeStamp option adds a timestamp to the verbose printout, which can be useful when logging events.

Format

-XverboseTimeStamp

You can force a timestamp to print out with other information generated by -Xverbose if you combine it with the command -XverboseTimeStamp.

Example

java -Xverbose -XverboseTimeStamp myApp

The printout generated by -XverboseTimeStamp precedes the information printed by -Xverbose, as follows:

L:\src>D:\jrockits\R28.0.0-617_1.6.0\bin\java -Xverbose
-XverboseTimeStamp HelloWorld
[load   ][Mon Sep 25 09:57:56 2006][00624] opened zip
D:\jrockits\R28.0.0-617_1.6.0\jre\lib\rt.jar

Related Options

The -XverboseTimeStamp option is only effective if verbose logging is enabled either by using -Xverbose or by enabling it at run time.

---

-Xverify

The -Xverify option allows you to manually verify the correctness of the bytecode. By performing these checks once at class loading time, as opposed to repeatedly during execution, this option helps improve run-time efficiency.

Format

-Xverify:parameter

Combine this option with one of the parameters described in Table 2-9.

Table 2-9 -Xverify Parameters

Parameter	Description
none	Does not verify the bytecode. Note: This parameter can reduce startup time, but you might lose some of the protection provided by Java.
remote	Verifies those classes loaded over network.
all	Verifies all classes.

Default Value

If you do not use -Xverify, by default, the JVM verifies only those classes loaded over the network (-Xverify:remote).

Related Options

-XX:+|-FailOverToOldVerifier