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
-Xoptions 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,
-Xgcand-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 |
gencon
Alias: genconcon
|
Generational, concurrent garbage collection. In the The |
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 |
genpar
Alias: genparpar
|
Generational garbage collection. In the This mode is generally better than the |
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. |
|
|
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 |
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. |
|
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 |
|
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 |
|
authenticate=true|false |
Enables or disables authentication. When this property is set to Related -D option: -Dcom.oracle.management.jmxremote.authenticate |
|
|
|
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 |
- |
|
|
Specifies the location of the file from which additional management configuration properties are loaded. Related -D option: -Dcom.oracle.management.config.file |
|
|
|
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 |
|
|
|
Enables or disables the local JMX connector. Related -D option: -Dcom.oracle.management.jmxremote |
|
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. |
|
|
Binds the RMI connector stub to an RMI registry protected by SSL. Related -D option: -Dcom.oracle.management.jmxremote.registry.ssl |
|
|
|
Enables or disables the remote JMX connector. |
|
|
|
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. |
|
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):
-
-servermode: 25% of the amount of free physical memory in the system, up to 64 MB and at least 8 MB. -
-clientmode: 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
-Xnsoption, 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
-Xmxand -Xms are specified the value of-Xmxmust be larger than or equal to that of-Xms. -
If both
-Xmxand -Xns are specified the value of-Xmxmust be larger than or equal to that of-Xns. -
The minimum value for
-Xmxis 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
-XpauseTargethas 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 |
|---|---|
|
|
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 [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 [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 |
|
|
Displays exception types and messages (excluding the common types of exceptions). Verbose output for [excepti][00002] java/lang/NumberFormatException: null |
|
|
Displays exception types and messages (excluding the common types of exceptions). It also displays stacktraces; Verbose output for [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
|
|
|
The same information as
|
|
|
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.
|
|
|
Information about the decisions that the garbage collection heuristics make and also the heap size changes. |
|
|
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 [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 |
|
|
Prints the same information as |
|
|
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
Output from [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 |
|
|
Prints information about the memory management system, including:
The information printed by |
|
|
Enables debug level for verbose modules that are useful when you debug memory-related issues. Verbose output for [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 [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) |
|
|
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. |
|
|
The values of [INFO ][startti] VM start time: 1260962573921 millis 6922526 nanos 18442244770397334 ticks Where:
|
|
|
Notifies of garbage collections started by a call to A garbage collection started by a direct call 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 |
|
|
The timer resolution and the method used to get a time value. This is the resolution of the timer used by the 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, |
info |
At the |
debug |
|
trace |
|
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 |
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 |
nanos |
Prints the same value that |
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 |
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