|
|
Non-standard, or -X, command line options are options that are exclusive to Oracle JRockit JVM that change the behavior of JRockit JVM to better suit the needs of different Java applications. These options are all preceded by -X and will not work on other JVMs (conversely, the non-standard options used by other JVMs won't work with JRockit JVM).
| Note: | Since these options are non-standard, they are subject to change at any time. |
This chapter is the complete reference to all -X startup flags that can be set in JRockit JVM. Each option is listed in alphabetical order.
This option specifies a semicolon-separated list of directories, JAR archives, and ZIP archives to search for boot class files. These are used in place of the boot class files included in the Java 2 SDK.
| Note: | Applications that use this option to override a class in rt.jar should not be deployed. Doing so would contravene the Java 2 Runtime Environment binary code license. |
Format: -Xbootclasspath <directories and zips/jars separated by ; (Windows) or : (Linux)>
Enter this option at startup to create the default classpath for bootstrap classes and resources. This option must be entered in lower case, not camel notation, as shown in the example.
This option is similar to -Xbootclasspath in that it specifies a semicolon-separated path of directories, JAR archives, and ZIP archives; however, this list is appended to the default bootstrap class path.
Format: -Xbootclasspath/a <directories and zips/jars separated by ; (Windows) or : (Linux)>
Enter this option at startup to append a list of directories, JAR archives, and ZIP archives to the default classpath for bootstrap classes and resources. This option must be entered in lower case, not camel notation, as shown in the example.
This option is similar to -Xbootclasspath in that it specifies a semicolon-separated path of directories, JAR archives, and ZIP archives; however, this list is prepended to the default bootstrap class path.
Format: -Xbootclasspath/p <directories and zips/jars separated by ; (Windows) or : (Linux)>
Enter this option at startup to prepend a list of directories, JAR archives, and ZIP archives to the default classpath for bootstrap classes and resources. This option must be entered in lower case, not camel notation, as shown in the example.
Enables additional checks for JNI functions.
Include this option at startup.
Use this option to define when the memory occupied by an object that has been garbage collected will be cleared. You can set objects clearing at allocation time, garbage collection time, or when a thread-local area is allocated.
| Note: | This option is deprecated as of the JRockit JVM R25. If you use it with that or any subsequent releases, the JVM will accept the option without throwing an exception, but nothing will happen. |
| Note: | The following information for -XclearType applies only to the JRockit JVM R24 and earlier. |
Set the desired parameter (<param>) as described in Table 2-1 to define the when object clearing will occur.
If -XclearType is not set, object clearing will default to the following:
-Xdebug enables debugging capabilities in the JVM which are used by the Java Virtual Machine Tools Interface (JVMTI). JVMTI is a low-level debugging interface used by debuggers and profiling tools. With it, you can inspect the state and control the execution of applications running in the JVM.
The subset of JVMTI that is most typically used by profilers is always available. However, the functionality used by debuggers to be able to step through the code and set breakpoints has some overhead associated with it and is not always available. To enable this functionality you must use the -Xdebug option.
| WARNING: | When running with -Xdebug the JVM is not running at its full speed. Thus, the option should not be used for applications when running in production environments. |
Include this option at startup.
java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n myApp
Use -Xgc to set a static garbage collector. The static garbage collectors are classified as in
Under some circumstances, the performance of these static garbage collectors might meet your needs better than the dynamic garbage collection modes or the default collectors available with the -server or -client flags. Additionally, if you want to use scripts written for the earlier versions of JRockit JVM that implement these collectors, those scripts will continue to work without requiring any modification—unless they use the generational copy garbage collector, which is no longer available.
Use -Xgc with one of the garbage collection types (<gcType>) listed in Table 2-3 to get the desired garbage collector algorithm:
When you specify -Xgc, the following options are affected:
-XXsetGC will override -Xgc and vice versa. The option specified first on the command line will be ignored.-Xgc will override part of the effect of -server and -client.
When using -Xgc, be aware of the following exceptions:
The -Xgcpause option prints out the pause times caused by the garbage collector during a run. The pause times are shown during runtime on your screen during the running of the application.
The effect of this option is identical to -Xverbose:gcpause.
Use this option at startup. As pauses are encountered, they will print a report to your screen, as shown in Listing 2-1.
[memory ] old collection phase 0-2 pause time: 100.794255 ms
[memory ] nursery collection pause time: 4.121775 ms
[memory ] nursery collection pause time: 185.137069 ms
[memory ] old collection phase 4-5 pause time: 147.672697 ms
[memory ] (pause includes yc: 142.537 ms, compaction: 1.317 ms, update ref: 1.41 3 ms)
[memory ] nursery collection pause time: 7.075705 ms
[memory ] old collection phase 5 pause time: 0.300176 ms
-XgcPrio sets a dynamic garbage collection mode. This garbage collector combines all types of garbage collection heuristics and optimizes the performance accordingly. When running this garbage collector, you only need to determine whether your application responds best to optimal memory throughput during collection or minimized pause times. The dynamic garbage collector will then adapt its choice of collector type, in runtime, to what is suiting your application the best.
| Note: | This command line option is supported with JRockit JDK 1.4.2_10 R26.2 and later versions, as well as all versions of JRockit JDK 5.0 and JRockit JDK 6. |
Combine -XgcPrio with one of the garbage collection types (<gcType>) described in Table 2-4:
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 may, however, cause non-deterministic 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.
|
|
The garbage collector is optimized for short pauses. This means that the garbage collection will work 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 200 ms. To change the default pause target, see -XpauseTarget.
|
|
The garbage collector is optimized for very short and deterministic pause times.The garbage collector will aim on keeping the garbage collection pauses below a given pause target. How well it will succeed depends on the application and the hardware. For example, a pause target on 30 ms has been verified on an application with 1 GB heap and an average of 30% live data or less at collection time, running on the following hardware:
Running on slower hardware, with a different heap size and/or with more live data might break the deterministic behavior or cause performance degradation over time, while faster hardware or less live data might allow you to set a lower pause target.
The pause target for deterministic mode is by default 30 ms, and can be changed with the command line option
-XpauseTarget |
-Xgcprio:throughput).-Xgc:singlecon)Use of -XgcPrio will affect certain options as described here:
-XgcPrio will override part of the effect of -server and -client.-Xns it overrides the dynamic nursery sizing; see
-Xns.
-XpauseTarget to set pause times for -XgcPrio:pausetime and XgcPrio:deterministic.
You cannot combine the dynamic garbage collector with a static garbage collector set with
-Xgc or
-XXsetGC.
If you set -XXdisableGCHeuristics, then there will be no change of garbage collection strategy as a result of the -XgcPrio option.
The -XgcReport option generates an end-of-run report that shows garbage collection statistics. You can use this report to determine if you’re using the most effective garbage collector for your application or not.
The report divides the statistics into “young collections” and “old collections”, and for each of the types the following information is printed:
The effect of this option is identical to -Xverbose:gcreport.
As shown in Listing 2-2, the -Xgcreport shows a detailed profile of collections on both the young generation and the old generation.
[memory ] Memory usage report
[memory ]
[memory ] young collections
[memory ] number of collections = 50
[memory ] total promoted = 4628936 (size 260614072)
[memory ] max promoted = 108102 (size 6083128)
[memory ] total GC time = 4.381 s
[memory ] mean GC time = 87.623 ms
[memory ] maximum GC Pauses = 125.264 , 153.122, 244.682 ms
[memory ]
[memory ] old collections
[memory ] number of collections = 6
[memory ] total promoted = 0 (size 0)
[memory ] max promoted = 0 (size 0)
[memory ] total GC time = 0.701 s (pause 0.701 s)
[memory ] mean GC time = 116.833 ms (pause 116.830 ms)
[memory ] maximum GC Pauses = 134.081 , 190.973, 215.381 ms
[memory ]
[memory ] number of parallel mark phases = 6
[memory ] number of parallel sweep phases = 4
[memory ] number of concurrent sweep phases = 2
Mon Nov 1 16:50:34 WEST 2004
This option tells the JRockit JVM 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: | While this option duplicates the functionality of -XXlargePages, this is the preferred option for enabling large pages. |
Windows, Linux and Solaris all support multiple page sizes on x86, IPF and SPARC architectures. x86 supports 4 KB and 4 MB (2 KB and 2 MB in PAE mode), while IPF and SPARC support a wider range of different sizes, from 4 KB to 256M, depending on model.
Format: -XlargePages:exitOnFailure=true
By default the JVM will continue running without large pages if large pages cannot be acquired when -XlargePages is enabled. Use this extended option to override this behavior and force the JVM to exit if enough large pages can’t be acquired. This extended option is supported in JRockit JVM R27.5 and later releases.
If you use this option, you will need to configure large pages on you machine. To do so, use one of the following procedures.
echo nn > /proc/sys/vm/nr_hugepages
Where nn is the number of desired pages.
You should do this step as soon as possible after the machine has been started since ongoing memory usage creates fragmentation and Linux might be unable to allocate the number of specified pages.
| Note: | The following steps might need to be completed by your system administrator, unless you have administrative privileges. |
hugetblfs file system available by using this command:mount -t hugetlbfs nodev /mnt/hugepages
mount command or with the chmod and chown commands.
For a more thorough description of large pages on Linux, read the file vm/hugetlbpage.txt available in the documentation for the Linux kernel.
Control Panel>Administrative>Tools>Local Security Policy>Local Policies>User Rights>Assignments>Lock pages in memory.
Nothing has to be configured in the O/S to enable an application to use large pages.
If the JRockit JVM fails to acquire large pages, it will print a warning and continue; for example:
[WARN ] Unable to acquire large pages for the heap, using normal pages
-XXlargePages is disabled by default.
This option starts the JRockit JVM concurrently with the management server and allows you to either enable and configure or explicitly disable security features such as SSL encryption and authentication.
Format: -Xmanagement[:<argument1>=<value1>[,<argument2>=<value2>]]
where argumentn and valuen is as defined in Table 2-5.
The implementation of this option in JRockit JVM R27.1.0 represents a change from previous versions of the product. In past versions, this option enabled the management server running:
The original RMP implementation had no security features. JRockit JVM 5.0 contains new security features—authentication and SSL encryption—that were introduced in J2SE 5.0, but similar security features were not enabled in the JRockit JVM 1.4.2.
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 don’t take these steps, the management server will not open a port for remote access and may cause the JVM startup to halt with an error message concerning the security configuration.
Specifying -Xmanagement also enables a local in-memory agent to improve the user experience from a developer perspective. For example, a developer running a WLS instance on JRockit JVM on a one machine can specify – Xmanagement 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, you would not need to specify -Xmanagement to get local access from JRockit Mission Control: the in-memory agent is always accessible locally. Thus, if you have a number of JRockit JVM instances running on your machine and you start a JRockit Mission Control Client, it will automatically discover and allow access to those JVMs. Security is enforced by only allowing this type of local access if the JRockit JVM instance and the JRockit Mission Control Client are being run by the same user. Note that this will only work if the monitored JRockit JVM is R27.1 and later.
To enable the management agent without security you must now specify that SSL and authentication should be disabled. Also, the JMX server port must now be specified explicitly with the JRockit JVM 5.0.
For maximum usability, you should also enable the autodiscovery mechanism, which allows JRockit Mission Control to automatically discover running JRockit JVM instances through the multicast based JRockit Discovery Protocol. Note that this will normally only work on the local subnet.
To limit the number of RMP connections running at the same time, you can set -Djrockit.managementserver.maxconnect.
The default value is based on the version of the JRockit JVM you are running:
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: | -Xms 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.
sets the initial and minimum java heap to 64 MB.
If you do not add a unit, you will get the exact value you state; for example, 64 will be interpreted as 64 bytes, not 64 megabytes or 64 kilobytes.
For best performance, set -Xms to the same size as the maximum heap size, for example:
java -Xgcprio:throughput -Xmx:64m -Xms:64m myApp
If you do not set this, the minimum Java heap size defaults to (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 -Xns, the default initial heap size will be scaled up to at least twice the nursery size.The initial Java heap cannot be set to a smaller value than 8 MB, which is the minimum Java heap size. If you attempt to set it to a smaller value, JRockit JVM defaults to 8 MB.
The -Xms value cannot exceed the value set for -Xmx (the maximum Java heap size).
This option sets the maximum 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. Depending upon the kind of operating system you are running, the maximum value you can set for the Java heap can vary.
| Note: | -Xmx does not limit the total amount of memory that the JVM can use. |
Format: -Xmx<size>[g|G|m|M|k|K]
Combine -Xmx with a memory value
sets the maximum java heap to 1 gigabyte.
If you do not add a unit, you will get the exact value you state; for example, 64 will be interpreted as 64 bytes, not 64 megabytes or 64 kilobytes.
The -Xmx option and -Xms option in combination are used to limit the Java heap size. The Java heap can never grow larger than -Xmx. Also, the -Xms value can be used as “minimum heap size” to set a fixed heap size by setting -Xms = -Xmx when, for example, you want to run benchmark tests.
The JRockit JVM R26.0.0 on Linux IA32 can experience problems setting up memory for object allocation. When this happens, you will receive the following message:
[JRockit] ERROR: Fatal error in JRockit during memory setup phase.
Try to reduce the heap size using -Xmx:<size>m, i.e. “-Xmx:16m”. Could
not create the Java virtual machine.
and JRockit JVM will be exited.
The workaround for this situation is to try different -Xmx values until you find a heap size that is setup correct.
| Note: | This known issue is valid for R26.0.0. |
If you do not set this, the maximum java heap size depends on the platform and the amount of memory in the system as described in Table 2-6.
When using-Xmx, be aware of the following exceptions:
This option disables garbage collection of classes. Using -XnoClassGC can save some garbage collection time, which will shorten interruptions during the application run.
When you specify -XnoClassGC at startup, the class objects in the application specified by myApp will be left untouched during garbage collection and will always be considered live. This can result in more memory being permanently occupied which, if not used carefully, will throw an out of memory exception.
This option helps to prevent possible interference when JRockit JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP. Upon receiving such events, the VM tries to initiate a shutdown but this shutdown will fail, since the operating system will not actually terminate the process.
| Note: | -Xnohup is similar to the Sun Microsystems command-line option -Xrs, developed for their HotSpot JVM. The JRockit JVM supports both -Xrs and -Xnohup. If you use -Xrs, you will see the same behavior that you would see with -Xnohup. |
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.
If you specify -Xnohup, be aware of the following:
This option turns off adaptive optimization. While optimized code generally runs faster than code that hasn’t been optimized, occasionally, the time required to optimize code results in undesirable delays processing. -XnoOpt lets you avoid 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.
Note that if you use -XnoOpt, you will continue to compile code that might be inefficient and might have a deleterious affect on application performance.
If -XnoOpt is not set, the JVM will optimize code as usual.
If you use
-XXnoJITInline, you must also use -XnoOpt. -XXnoJITInline only disables inlining the first time a method is compiled. Unless you set -XnoOpt as well, methods can still be inlined when code is optimized.
-Xns sets the nursery size. the JRockit JVM uses a nursery when the generational garbage collection model is used, that is, when the dynamic garbage collector has determined that the generational garbage collection model should be used or when the static generational concurrent garbage collector (
-Xgc
:
gencon) has been selected. You can also use -Xns to set a static nursery size when running a dynamic garbage collector (-XgcPrio).
Format: -Xns:<size>[g|G|m|M|k|K]
Combine -Xns with a memory value
sets the nursery to 10 MB of the heap.
The nursery size value cannot exceed the maximum value set for the heap.
Default value depends upon whether you use a dynamic garbage collector (the default garbage collector) or the select a static garbage collector, see Table 2-7
When using -Xns, be aware of the following exceptions:
-Xns only when using a dynamic garbage collector (-XgcPrio) or a static generational garbage collector (-Xgc:gencon or -Xgc:genpar).
-XXlargeObjectLimit and it may not be greater than
-Xmx.
This option sets a pause target for the dynamic garbage collection mode optimizing for short pauses (
-XgcPrio
:
pausetime) and the dynamic garbage collection mode optimizing for deterministic pauses (
-XgcPrio
:
deterministic). The target value is used as a pause time goal. The target helps the dynamic 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 ms and 5 seconds. If you are using the deterministic garbage collector, you can set values below 200 ms you must have a valid license for
-XgcPrio
:
deterministic.
Format: -XpauseTarget=<target value>
-XpauseTarget=<target value> -Xgcprio:pausetime
Remember that the target set by this option is considered a soft goal; that is, if specifying the target to 100 ms, the garbage collector will try to tune itself towards a configuration that will make the pauses become as near 100 ms as possible. However, if you have an application and heap configuration that will not be able to meet this target however much the garbage collector is tuned (statically or dynamically), the target will be missed. This option only specified the desired pause times, not the maximum allowed pause time.
Used with care this option will improve pause times, however if used with less care, it might stress the garbage collector to less appreciated behavior.
If you are using -XpauseTarget with
-XgcPrio
:
pausetime, the default setting for the target is 500 ms. If you are using
-XgcPrio
:
deterministic, the default value is 30 ms.
Normally, this option requires that you use it with a dynamic pause optimizing garbage collection mode (
-XgcPrio
:
pausetime or
-XgcPrio
:
deterministic
). If you don’t specify a garbage collector, this option will change from the default garbage collector to the pause time optimizing garbage collector (the same collector used when specifying
-XgcPrio
:
pausetime).
If you are using Oracle JRockit Real Time, set -XgcPauseTarget to below 200 ms, and don’t specify a garbage collector, the garbage collector will be set to
-XgcPrio
:
deterministic.
When using -XpauseTarget, be aware of the following exceptions:
| Note: | -Xrs is a non-standard option developed by Sun Microsystems for their HotSpot JVM. JRockit JVM continues to support this option; however the JRockit JVM non-standard option -Xnohup provides 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 will 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.
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.
If you specify -Xnohup, be aware of the following:
This option loads the JPDA reference implementation of JDWP. This library resides in the target VM and uses JVMDI and JNI to interact with it. It uses a transport and the JDWP protocol to communicate with a separate debugger application.
Format: -Xrunjdwp:<name1>[=<value1>],<name2>[=<value2>]...
The -Xrunjdwp option can be further qualified by specifying one of the sub-options listed in Table 2-8.
java-Xrunjdwp:transport=dt_socket,server=y,address=8000myApp
java.io.IOException to be thrown in this VM. suspend=y by default). /usr/local/bin/debugstub dt_socket myhost:8000This program can launch a debugger process in a separate window which will attach to this VM and begin debugging it.
-Xrunjdwp:transport=dt_shmem,server=y,onuncaught=y,launch=d:\bin\debugstub.exe
d:\bin\debugstub.exe dt_shmem <address>
where <address> is the selected shared memory address.
This program can launch a debugger process in a separate window which will attach to this VM and begin debugging it.
-Xss 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
sets the default stack size to 512 kilobytes.
If you do not add a unit, you will get the exact value you state; for example, 64 will be 64 bytes, not 64 megabytes or 64 kilobytes.
-Xss default values are platform-specific, as defined in Table 2-9.
This option enables strict floating point arithmetics globally for all methods in all classes. With -XstrictFP set, the JVM calculates with more precision, and with a greater range of values than the Java specification requires. When you use -XstrictFP, the compiler generates code that adheres strictly to the Java specification to ensure identical results on all platforms. Without -XstrictFP, the JVM will not be as strict in enforcing floating point values.
This option is similar to the Java keyword strictfp; however, that keyword applies at the class level whereas -XstrictFP applies globally. See the
Java Language Specification for more details on strictfp.
-Xverbose lets JRockit JVM output 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 hyper threading is enabled. Table 2-10 lists the parameters available for the -Xverbose option.
Format: -Xverbose:<param[=level]>
Where param is one of the parameters described in Table 2-10 and level the log level, as described in Log Levels.
java -Xverbose:gcpause=debug myClass
enables pause time sampling and information during a run and logs messages with detailed information of JRockit JVM’s behavior.
| Note: | To use more than one parameter, separate them with a comma; for example: |
| Note: | -Xverbose:gc,opt |
[INFO ][class ] Initializing bootstrap classes...
|
|||
[codegen] 0 : 17.9411 ms
|
|||
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
|
|||
[INFO ][load ] opened zip
|
|||
Turns on memory printout and adds new special
memdbg printouts. Verbose output for memdbg might look like this:
[memory ] 12.875: nursery GC 89648K->89716K (89716K), 3.296 ms
|
|||
Turns on memory printout and adds new special
memdbg printouts. A report for a JVM running a dynamic garbage collector optimized for application throughput (
-XgcPrio
:
throughput) with memdbg specified might look like this:
[memdbg ] nursery GC 3: promoted 22788 objects (1246K) in 28.472 ms
|
|||
|
|||
A report for a JVM running a generational concurrent collector (
-Xgc:gencon) with memory or gc specified might look like this:
[memory ] GC strategy: gencon
|
|||
A report for a JVM running a single generation concurrent collector (
-Xgc:singlecon) with memory or gc specified might look like this:
[memory ] GC strategy: singlecon
|
|||
A report for a JVM running a parallel collector (
-Xgc:parallel) with memory or gc specified might look like this:
[memory ] GC strategy: parallel
|
|||
A report for a JVM running a dynamic garbage collector optimized for application throughput (-XgcPrio:throughput) with
memory or gc specified might look like this:
[memory ] GC strategy: System optimized over throughput (initial strategy singleparpar)
|
|||
The reference objects for each old generation garbage collection and the reference to which they point.
-Xverbose:referents corresponds to the option -Djrockit.verboserefs in earlier JRockit JVM versions, prior to R27.2.
Each reference type is broken down by reference class and referent. In the case of handles, only referents are shown; there are no references. The different counters tell how many instances of each type exists and how they are reachable (or cleared).
The header/footer of the report informs what type of collection took place, how long ago the last old collection happened and how much memory that was free at that time is reported. If any soft references are present the user is told which softly reachable referents are collected based on when they where last looked up through
get().
|
|||
Information on reference objects and handles at each garbage collection. At info level 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 reachability 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.
At debug level this module displays an improved version of the information previously displayed by
-Xverbose:referents.
|
|||
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:
[startti] VM start time: 1152871839957 millis 171588375730523 nanos
|
|||
Notifies of garbage collections started by a call to
System.gc() or for a reason marked as “other” in JRA recordings 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() will result in a verbose output similar to:
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 will have the reason for the garbage collection printed out, for example:
|
|||
Gives the same output as referents.
|
Log levels identify the levels of information recorded in the log. JRockit JVM uses six logging levels, as described in Table 2-11.
-Xverbose must be set for the following options to work:
Use this option to set the “decorations” JRockit JVM adds to verbose printouts. Decorations are additional information—usually system-related—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.
Format: -Xverbosedecorations=<decoration names>
java -Xverbose:gcpause-XverboseDecorations=timestamp,modulemyApp
at startup, the output will include these decorations:
| Note: | You can also use the control-break handler verbosity with the argument decorations. |
The possible decorations are listed in Table 2-12.
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.
|
|
Prints a human readable timestamp. This is the same value you would receive if you used the
-XverboseTimeStamp option.
|
If you use -XverboseDecorations without specifying a decoration, the verbose output will display the module, timestamp, and pid (in that order); for example:
D:\jrockits\R27.1.0_R27.1.0-23_1.4.2\bin>java -Xverbose:load -Xverbosedecorations -cp L:\src\ HelloWorld
[load ][Wed Sep 13 19:43:14 2006][00728] opened zip D:\jrockits\R27.1.0_R27.1.0-23_1.4.2\jre\lib\rt.jar
This option can only be used if
-Xverbose is also set, as that option turns on verbose logging.
This 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 will write any logging information to the specified file.
java -Xverbose:gcpause-Xverboselog:verboseText.txtmyApp
writes verbose logging information for the class myApp to a file called verboseText.txt
This option can only work if -Xverbose is set, as that option turns on verbose logging.
This option does not print to screen.
This option adds a timestamp to the verbose printout, which can be useful when logging events.
You can force a timestamp to print out with other information generated by -Xverbose if you combine it with the command -XverboseTimeStamp.
java -Xverbose-XverboseTimeStampmyApp
The printout generated by -XverboseTimeStamp will precede the information printed by
-Xverbose, as shown here:
L:\src>D:\jrockits\R27.1.0_R27.1.0-13_1.4.2\bin\java -Xverbose
-XverboseTimeStamp HelloWorld[load ][Mon Sep 25 09:57:56 2006][00624] opened zip
D:\jrockits\R27.1.0_R27.1.0-13_1.4.2\jre\lib\rt.jar
This option is only effective if verbose logging is enabled either by using
-Xverbose or by enabling it at runtime.
This 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 runtime efficiency.
Combine this option with one of the parameters described in Table 2-13.
If you don’t use this option, the default is to verify just those classes loaded over the network (-Xverify:remote).
|