This command is used to check the state of the JRockit Flight Recorder engine. For more information on JRockit Flight Recorder, see Chapter 8, The Runtime Analyzer, and Chapter 9, The Flight Recorder. The corresponding command for R27 is checkjrarecording. This command normally always returns at least one ongoing recording. This is because most versions of R28 run with a low overhead recording always enabled. As there can be multiple recordings running in parallel, the command takes as argument the ID of the recording for which to retrieve the status. If -1 or no argument is supplied, the status of all ongoing recordings will be shown. The recordings can also be referenced by name through the name parameter. The continuously running recording, where available, can for example be referred to by the name continuous.

For example:

C:>jrcmd 6328 check_flightrecording name=continuous verbose=true
6328:
Recording : id=0 name="continuous" duration=0s (running)
http://www.oracle.com/jrockit/jvm/:
java/alloc/accumulated/thread : disabled period=1000
java/alloc/accumulated/total : enabled period=0
java/alloc/object/in_new_tla : disabled threshold=10000000
java/alloc/object/outside_tla : disabled threshold=10000000
java/exception/stats : enabled period=1000
java/exception/throw : disabled period=1000
java/file/read : disabled threshold=10000000
java/file/write : disabled threshold=10000000
java/monitor/enter : disabled threshold=10000000
java/monitor/profile : disabled period=1000
java/monitor/wait : disabled threshold=10000000
java/socket/read : disabled threshold=10000000
java/socket/write : disabled threshold=10000000
java/thread/end : enabled period=0
java/thread/park : disabled threshold=10000000
java/thread/sleep : disabled threshold=10000000
java/thread/start : enabled period=0
vm/class/load : disabled threshold=10000000
vm/class/memory/free : enabled threshold=0

If the verbose argument is set to false, the listing simply consists of one line per recording, with recording id, name, and duration. The verbose listing, as shown in this example, lists all the active event producers, and for each producer the status for each event type. The listing starts with the recording name and the status for the recording. In the previous example, it can be seen that the continuous recording is active and that its ID is 0. We can see that for the http://www.oracle.com/jrockit/jvm/ producer, there are quite a few event types available, and that only some of them are enabled.

See start_flightrecording, stop_flightrecording and dump_flightrecording.

This is a very simple command that is useful together with the startjrarecording command. It is used for checking if there is already an active ongoing recording in a JRockit instance. If a JRA recording is currently in progress, the options used when that recording was initiated will be shown. The following example shows the result of running the checkjrarecording command nine seconds into a JRA recording.

C:>jrcmd 5516 checkjrarecording
5516:
JRA is running a recording with the following options:
filename=D:myrecording.jra, recordingtime=120s, methodsampling=1, gcsampling=1, heapstats=1, nativesamples=0, methodtraces=1, sampletime=5,zip=1, hwsampling=0, delay=0s, tracedepth=64 threaddump=1, threaddumpinterval=0s, latency=1, latencythreshold=20ms, cpusamples=1, cpusampleinterval=1s
The recording was started 9 seconds ago.
There are 111 seconds left of the recording.

The JRA recording was started using the command line from the startjrarecording example, given later in this chapter

See startjrarecording and stopjrarecording.

Sometimes it can be useful to be able to examine the command line that launched a particular JVM. Perhaps a JVM subsystem, like the garbage collector, is behaving peculiarly because a parameter was set to a suboptimal value at startup. Or maybe we want to find out how the management agent was initialized on the command line—for example, was SSL really enabled, and if so, was the keystore really the right one?

The command_line command shows the parameters a JVM was started with. Note that the command line is reconstructed from what was actually supplied to the JVM from the launcher, and may include parameters that were not explicitly passed to the JVM by the user.

Following is an example of what can be shown if the command is executed on an instance of JRockit running JRockit Mission Control, with some additional parameters set:

C:>jrcmd 2416 command_line
2416:
Command Line: -Denv.class.path=.;C:Program Files Javajre6libextQTJava.zip -Dapplication.home=C:jrockitsR28.0.0_ R28.0.0-547_1.6.0 -client -Djrockit.ctrlbreak.enableforce_crash=true -Dsun.java.launcher=SUN_STANDARD com.jrockit.mc.rcp.start.MCMain -Xmx512m -Xms64m -Xmanagement:port=4712,ssl=false,authenticate=false

This command is useful for retrieving the contents of an ongoing recording without having to halt it. The idea is to never stop the continuous recording that is enabled by default in the JVM (for most versions of R28). The command basically clones the recording, stops the cloned recording, and writes it to disk.

For example:

C:>jrcmd 7420 dump_flightrecording recording=0 copy_to_file=my_continuous_snapshot.jfr.gz compress_copy=true

This example takes the JRockit Flight Recorder recording with ID 0, clones it, stops the clone, and writes the contents to the file my_continous_snapshot.jfr.gz, as specified by the copy_to_file argument. The recording with ID 0 is normally the continuous recording that is always running in the JVM. The recording to clone can also be specified by name using the name parameter, in this case, we would use name=continuous. As the compress_copy argument was set to true, the resulting file will be gzip compressed.

See start_flightrecording, stop_flightrecording, and check_flightrecording.

The heap_diagnostics command provides detailed information about the heap usage in a virtual machine, including information on reference object usage. Executing the command triggers a full garbage collection during which the information is gathered. The command takes no arguments and returns the diagnostic information.

The output contains three main sections.

The first section in the diagnostic dump lists some general information about the system, such as available memory and heap usage.

C:>jrcmd 7420 heap_diagnostics
7420:
Invoked from diagnosticcommand
======== BEGIN OF HEAPDIAGNOSTIC =========================
Total memory in system: 3706712064 bytes
Available physical memory in system: 1484275712 bytes
-Xmx (maximal heap size) is 1073741824 bytes
Heapsize: 65929216 bytes
Free heap-memory: 8571400 bytes

The next section, Detailed Heap Statistics, is basically the same output as from the print_object_summary command, but without the optional points-to information. Also, there is no cut-off for this summary—all classes in the system will be listed, so expect the result to be quite long. There is one line of output per class in the system.

The next section, Reference Objects statistics, contains detailed information on the use of reference objects, such as weak references. The reference objects are also listed per type (class). Under each type, there is a listing grouped by what objects they point to, or in the case of finalizers, their declaration type.

In this example, we can see that most of the weak references in the system point to Strings. The weak references are the ones referenced by java.lang.ref.WeakReference. There are in total 3,084 weak references in the system, of which 2,607 are reachable. For soft references, we can see that the current objects pointed out by soft references survived for at least 198 seconds.

The heap_diagnostics command is quite useful for doing coarse grained analysis of the use of reference objects and for getting statistics on heap usage. However, it is usually easier to use the JRockit Mission Control Memleak Tool and/or JRockit Flight Recorder.

See print_object_summary.

Sometimes it can be useful to dump the heap for offline analysis, as opposed to the online analysis available through the Memleak tool in JRockit Mission Control. As of version R28, JRockit can produce heap dumps in the popular HPROF format. There are quite a few memory analysis tools available that operate on HPROF dumps, for instance the excellent Eclipse Memory Analyzer Tool (MAT).

For example:

C:>jrcmd 7772 hprofdump filename=mydump.hprof
segment_threshold=2G segment_size=1G
7772:
Wrote dump to mydump.hprof

The segment_threshold and segment_size arguments can be used to split the dump into several smaller files whenever the heap usage is larger than convenient. In the previous example, the split would occur if the heap usage was more than two gigabytes, and JRockit would then attempt to dump the memory in several one gigabyte chunks.

The files will be written to the JROCKIT_HOME directory. The filename is optional—if no filename is provided, a date-stamped file name will be provided, for example:

C:>jrcmd 7772 hprofdump
7772:
Wrote dump to heapdump_Tue_Sep_22_19_09_16_2009

See memleakserver and oom_diagnostics.

This command is used to shut down the external management server. Note that the command is not called "stop_management_server". This is purely for legacy reasons. Once upon a time any command name that began with "stop" was interpreted as a command to stop parsing the ctrlhandler.act file.

The kill_management_server command takes no arguments.

C:>jrcmd 7772 kill_management_server
7772:

See start_mangement_server.

Certain JVM parameters can be set on the command line using the -XX:<Flag>=<value> syntax. As explained in Chapter 1, these parameters are known as VM flags, and can be listed using the list_vmflags command.

For example:

C:>jrcmd 7772 list_vmflags describe=true alias=true
Global:
UnlockDiagnosticVMOptions = false (default, writeable)
- Enable processing of flags relating to field diagnostics
UnlockInternalVMOptions = false (default)
- Enable processing of internal, unsupported flags
Class:
FailOverToOldVerifier = true (default, writeable)
- Fail over to old verifier when split verifier fails
UseVerifierClassCache = true (default)
- Try to cache java.lang.Class lookups for old verifier.
UseClassGC = true (default)
(Alias: -Xnoclassgc)
- Allow GC of Java classes
...
Threads:
UseThreadPriorities = false (default)
- Use native thread priorities
DeferThrSuspendLoopCount = 4000 (default, writeable)
- Number of iterations in safepoint loop until we try blocking
...

There are quite a lot of flags available, so only a short subset is shown in this example. Some of the flags are writable and can be changed at runtime using the set_vmflag command. Other VM flags can only be set at startup.

See set_vmflag.

This command is only available if the JVM is running with lock profiling enabled, by using -XX:UseLockProfiling=true and/or -XX:UseNativeLockProfiling=true, as described in Chapter 4. It outputs a lock profile similar to the one available in JRockit Mission Control.

C:>jrcmd 1442 lockprofile_print
1442:
Class, Lazy Banned, Thin Uncontended, Thin Contended, Lazy Reservation, Lazy lock, Lazy Reverted, Lazy Coop-Reverted, Thin Recursive, Fat Uncontended, Fat Contended, Fat Recursive, Fat Contended Sleep, Reserve Bit Uncontended, Reserve Bit Contended
[B, false, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
java/lang/Thread, false, 11, 0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
java/security/Permissions, false, 0, 0, 2, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0
java/util/Hashtable, false, 0, 0, 34, 524, 1, 0, 0, 0, 0, 0, 0, 0, 0
java/lang/Class, false, 0, 0, 24, 77, 2, 0, 0, 0, 0, 0, 0, 0, 0
java/lang/Object, false, 1, 0, 11, 139572, 1, 0, 0, 1, 0, 0, 0, 6, 0
java/lang/StringBuffer, false, 0, 0, 137, 773, 0, 0, 0, 0, 0, 0, 0, 0, 0
sun/nio/cs/StandardCharsets, false, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
java/util/Properties, false, 0, 0, 5, 479, 0, 0, 0, 0, 0, 0, 0, 0, 0
java/lang/ThreadGroup, false, 0, 0, 3, 16, 1, 0, 0, 0, 0, 0, 0, 0, 0
java/lang/ref/Reference$ReferenceHandler, false, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
sun/security/provider/Sun, false, 0, 0, 39, 5589, 0, 0, 0, 0, 0, 0, 0, 0, 0
java/io/PrintStream, false, 0, 0, 7, 7818, 0, 0, 0, 0, 0, 0, 0, 0, 0
java/net/URL, false, 0, 0, 70, 68, 0, 0, 0, 0, 0, 0, 0, 0, 0
java/io/ByteArrayInputStream, false, 0, 0, 47, 1115, 0, 0, 0, 0, 0, 0, 0, 0, 0
java/io/ByteArrayInputStream, false, 0, 0, 47, 1115, 0, 0, 0, 0, 0, 0, 0, 0, 0
java/util/logging/Logger, false, 0, 0, 2, 18, 0, 0, 0, 0, 0, 0, 0, 0, 0
jrockit/vm/CharBufferThreadLocal, false, 0, 0, 2, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0
java/security/Provider$Service, false, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
java/lang/Runtime, false, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
java/lang/reflect/Field, false, 0, 0, 8, 8, 0, 0, 0, 0, 0, 0, 0, 0, 0
java/util/Random, false, 0, 0, 6, 18556549, 1, 0, 0, 0, 0, 0, 0, 0, 0

See lockprofile_reset.

This command is only available if the JVM is running with lock profiling enabled, by using -XX:UseLockProfiling=true and/or -XX:UseNativeLockProfiling=true, as described in Chapter 4. It resets all profile counters to zero for the current lock profile.

See lockprofile_print.

This command is for starting and stopping the native Memory Leak Server (MLS). The JRockit Memory Leak Detector uses its own native server, the MLS, for communication. This server is normally automatically started over JMX, but sometimes it may make sense to start the server explicitly. It may, for instance, be necessary to start only the MLS without starting the JMX agent. The memleakserver command can be used to control the lifecycle of the MLS. The command works as a toggle; executing the command twice will first start the MLS and then shut it down.

The following example starts the MLS on port 7899:

C:>jrcmd 5516 memleakserver port=7899
5516:
Memleak started at port 7899.

Executing the command again will shut down the server.

C:>jrcmd 5516 memleakserver port=7899
5516:

Stopping the server does not produce any output.

See hprofdump.

This command was renamed heap_diagnostics in R28.

See heap_diagnostics.

Sometimes it can be helpful to know if a certain class has been loaded by the JVM. For example, dynamic class loading may be used with an SPI framework, and when it fails to work as expected, a useful start may be to find out if the classes that should have been contributed by the framework were even loaded at all. One way of finding this out would be to have the JVM dump the names of all the loaded classes in the system and grep for the specific class being sought. Executing print_class_summary simply dumps the names of the classes like this:

C:>jrcmd 5516 print_class_summary
5516:
- Class Summary Information starts here
class java/lang/Object
*class java/util/Vector$1
*class sun/util/calendar/CalendarUtils
*class sun/util/calendar/ZoneInfoFile$1
*class sun/util/calendar/ZoneInfoFile
*class sun/util/calendar/TzIDOldMapping
*class java/util/TimeZone$1
*class java/util/TimeZone
**class java/util/SimpleTimeZone
**class sun/util/calendar/ZoneInfo
*class sun/util/calendar/CalendarDate
**class sun/util/calendar/BaseCalendar$Date
***class sun/util/calendar/Gregorian$Date
*class sun/util/calendar/CalendarSystem
**class sun/util/calendar/AbstractCalendar
***class sun/util/calendar/BaseCalendar
****class sun/util/calendar/Gregorian
...

As can be seen from the previous example, the output is sorted in the form of an inheritance tree, with the stars denoting the depth in the tree. The following example shows how to find all loaded classes containing the string LoadAnd on a *NIX system:

$ jrcmd 5516 print_class_summary | grep LoadAnd
*class LoadAndDeadlock
**class LoadAndDeadlock$LockerThread
**class LoadAndDeadlock$AllocThread

This command shows the length of the code generation queue and the optimization queue in a JVM at the current time. An optional boolean argument, list, can be given to also show the contents of the queues, i.e. a list of methods and their generation order for the optimizer and the JIT.

C:>jrcmd 1442 print_codegen_list list=true
1442:
-------------------------------------------------------
format: <position> <directive no> <method description>
strategies: q=quick, n=normal, o=optimize
JIT queue: 0 methods in queue
OPT queue:
0: 1 java/math/BigDecimal.<init>(Ljava/math/BigInteger;JII)V
1: 1 java/math/BigDecimal.add (Ljava/math/BigDecimal;)Ljava/math/BigDecimal;
2: 1 java/lang/String.<init>([C)V
3: 1 java/util/TreeMap$NavigableSubMap.size()I
4: 1 java/util/TreeMap$NavigableSubMap.setLastKey()V
5: 1 jrockit/vm/Strings.compare(Ljava/lang/String;Ljava/lang/String;)I
6: 1 com/sun/org/apache/xerces/internal/dom/CharacterDataImpl. setNodeValueInternal(Ljava/lang/String;Z)V
7: 1 com/sun/org/apache/xerces/internal/dom/ CoreDocumentImpl.changed()V
8: 1 java/lang/String.getChars(II[CI)V
9: 1 com/sun/org/apache/xerces/internal/dom/NodeImpl.appendChild (Lorg/w3c/dom/Node;)Lorg/w3c/dom/Node;
10: 1 spec/jbb/Warehouse.getAddress()Lspec/jbb/Address;
11: 1 jrockit/vm/ArrayCopy.copy_checks_done2 (Ljava/lang/Object;ILjava/lang/Object;II)V
12 methods in queue

As has been explained in previous chapters, JRockit uses memory for things other than just the Java heap. Sometimes, when too much memory is in use by the Java heap, JRockit can run out of native memory. The print_memusage command is very useful for finding out how JRockit is utilizing system memory. Here is an example of the memory usage for a JRockit JVM running an Eclipse instance:

C:>jrcmd 484536 print_memusage
484536:
[JRockit] memtrace is collecting data...
[JRockit] *** 0th memory utilization report
(all numbers are in kbytes)
Total mapped ;;;;;;;1298896
; Total in-use ;;;;;; 438768
;; executable ;;;;; 28460
;;; java code ;;;; 5952; 20.9%
;;;; used ;;; 5647; 94.9%
;; shared modules (exec+ro+rw) ;;;;; 35912
;; guards ;;;;; 528
;; readonly ;;;;; 25936
;; rw-memory ;;;;; 376392
;;; Java-heap ;;;; 262144; 69.6%
;;; Stacks ;;;; 3472; 0.9%
;;; Native-memory ;;;; 110775; 29.4%
;;;; java-heap-overhead ;;; 8206
;;;; codegen memory ;;; 896
;;;; classes ;;; 43008; 38.8%
;;;;; method bytecode ;; 4477
;;;;; method structs ;; 3895 (#83104)
;;;;; constantpool ;; 18759
;;;;; classblock ;; 1596
;;;;; class ;; 3041 (#8403)
;;;;; other classdata ;; 8280
;;;;; overhead ;; 34
;;;; threads ;;; 24; 0.0%
;;;; malloc:ed memory ;;; 22647; 20.4%
;;;;; codeinfo ;; 1231
;;;;; codeinfotrees ;; 429
;;;;; exceptiontables ;; 125
;;;;; metainfo/livemaptable ;; 5883
;;;;; codeblock structs ;; 2
;;;;; constants ;; 14
;;;;; livemap global tables ;; 994
;;;;; callprof cache ;; 0
;;;;; paraminfo ;; 146 (#1979)
;;;;; strings ;; 8376 (#148622)
;;;;; strings(jstring) ;; 0
;;;;; typegraph ;; 2009
;;;;; interface implementor list ;; 40
;;;;; thread contexts ;; 19
;;;;; jar/zip memory ;; 5378
;;;;; native handle memory ;; 19
;;;; unaccounted for memory ;;; 36017; 32.5%;1.59
---------------------!!!

From the listing, we can see that the JRockit process has reserved more than a gigabyte of memory. This may sound excessive, but JRockit is only using less than 429 MB of the allocated gigabyte. Out of those, around 60 percent is used for the Java heap.

The listing is hierarchical—each allocation node has sub-nodes (for example "malloc:ed memory" is used for native structure inside the JVM: livemaps, the type graph, and so on). The percentage notation listed in the margin may seem a little bit confusing at first, as it is calculated as a percentage of the total of the parent node. There is no percentage calculated for the topmost nodes—the 60 percent used by the Java heap mentioned in the previous example was calculated manually and not given by the printout (262,144/438,768 * 100 = 59.7%)

This command may come in handy for tracking down a native memory leak. Such a memory leak can, for example, be caused by a native agent like a third party JVMTI agent.

Similar to the R27 version of this command, print_memusage in R28 is used for finding out how JRockit is utilizing its memory. In R28, the command has been improved.

This command is very useful to find out why the JRockit process is running out of memory. The cause is usually unintentional object retention, as described in Chapter 10, but sometimes the reason is not directly related to objects on the Java heap. Mismanagement of native resources can also cause leaks. Common examples are having an excessive number of java.util.zip.GZIPOutputStreams open, class loaders holding on to classes, or leaks in third-party JNI code

For example:

C:>jrcmd 7772 print_memusage
7772:
Total mapped 1281284KB (reserved=1002164KB)
- Java heap 1048576KB (reserved=932068KB)
- GC tables 35084KB
- Thread stacks 11520KB (#threads=27)
- Compiled code 5696KB (used=5490KB)
- Internal 840KB
- OS 67712KB
- Other 48048KB
- JRockit malloc 29184KB (malloced=27359KB #275574)
- Native memory tracking 1024KB (malloced=537KB #11)
- Java class data 33600KB (malloced=33471KB #41208)

The first column contains the name of a memory space and the second column shows how much memory is mapped for that space. The third column contains details. In the previous example, we can conclude that most of the memory is occupied by the Java heap, which would normally be the case.

When tracking native memory leaks, it is useful to look at how much the memory usage changes over time. The argument baseline is used to establish a point from which to start measuring.

The scale argument modifies the unit of the amounts of memory in the printout. The default is kilobytes.

For example, use scale=M to get the units in megabytes instead:

C:>jrcmd 7772 print_memusage scale=M baseline
7772:
Total mapped 1252MB (reserved=978MB)
- Java heap 1024MB (reserved=910MB)
- GC tables 34MB
- Thread stacks 11MB (#threads=27)
- Compiled code 5MB (used=5MB)
- Internal 0MB
- OS 66MB
- Other 47MB
- JRockit malloc 28MB (malloced=26MB #275601)
- Native memory tracking 1MB (malloced=0MB #11)
- Java class data 32MB (malloced=32MB #41208)

The baseline argument can be used to perform differential analysis. Once print_memusage is executed with the baseline argument, subsequent calls will include differentials against the baseline. For example:

C:>jrcmd 7772 print_memusage scale=M
7772:
Total mapped 1282MB +30MB (reserved=984MB +6MB)
- Java heap 1024MB (reserved=910MB)
- GC tables 34MB
- Thread stacks 14MB +3MB (#threads=35 +8)
- Compiled code 6MB +1MB (used=6MB)
- Internal 0MB
- OS 70MB +4MB
- Other 49MB +2MB
- JRockit malloc 41MB +13MB (malloced=34MB +8MB #330019 +54418)
- Native memory tracking 2MB (malloced=1MB #21 +10)
- Java class data 38MB +6MB (malloced=38MB +6MB #48325 +7117)

In this case we can see that, after the baseline was set, the process mapped in another 30 MB of memory, of which six more were reserved. We added another eight threads, and JRockit allocated an additional 8 MB. There is now in total 330,019 malloc objects on the JRockit native heap, an increase of 54,418. This resulted in a 13 MB increase in virtual memory usage.

void * foo = malloc(512);

To reset baseline and continue getting the readouts without the comparisons, the reset argument is used:

C:>jrcmd 7772 print_memusage reset

The argument trace_alloc_sites enables tracing of allocation sites where native allocations are made. Set trace_alloc_sites to 1 to enable tracing, and to 0 to disable it. To trace all allocations, even the ones occurring during startup of the JVM, the environment variable TRACE_ALLOC_SITES can be set to 1, as an override.

Once tracing has been enabled, memory allocations can then be displayed with different levels of detail using the level argument. If a baseline has been set, only the sites where changes have occurred are listed. For example:

C:>jrcmd 5784 print_memusage level=1
5784:
Total mapped 1300092KB +25040KB (reserved= 1090888KB -7496KB)
- Java heap 1048576KB (reserved= 1008068KB -11020KB)
- GC tables 35084KB
- Thread stacks 14336KB +3840KB (#threads=32 +9)
- Compiled code 4928KB +1152KB (used=4774KB +1209KB)
- Internal 1416KB +256KB
- OS 83040KB +2048KB
- Other 50312KB +2448KB
- JRockit malloc 27200KB +7424KB (malloced=25807KB +6236KB #266150 +63919)
balance 44KB +9KB (#23 +5)
breakpoints 9KB -8KB (#37 -255)
breaktable 8KB +2KB (#13 +3)
codealloc 56KB +25KB (#1037 +502)
codeblock 143KB +39KB (#2567 +686)
codeinfo 1224KB +351KB (#22300 +6404)
codeinfotree 400KB +126KB (#74 +18)
dynarray 116KB +30KB (#2058 +392)
finalhandles 3KB +2KB (#14 +7)
hashtable 32KB +32KB (#5 +3)
implchange 982KB +354KB (#20920 +7556)
javalock 279KB +266KB (#4477 +4092)
libcache 245KB +47KB (#9473 +1840)
libconstraints 22KB +3KB (#464 +75)
lifecycle 14KB +4KB (#33 +9)
livemap_system 1083KB +305KB (#25117 +5207)
memleak_trends 544KB +544KB (#5809 +5809)
memleakserver 96KB +96KB (#2906 +2906)
metainfo 7669KB +1916KB (#21935 +6416)

In the previous example, the JRockit Mission Control Memleak tool was started on a JVM monitoring itself between the invocations of the command. It can be seen how the Memleak modules have allocated a small amount of native memory. Raising the level to 4, even the source code lines in the JVM responsible for the allocations can be determined:

C:>jrcmd 5784 print_memusage level=4
5784:
Total mapped 1310708KB +35656KB (reserved=1083664KB -14720KB)
- Java heap 1048576KB (reserved=1002572KB -16516KB)
- GC tables 35084KB
108KB
+32KB (#27 +8)
update_trends memleak_trends.c: 364 592KB
+592KB (#3612 +3612)
update_trends memleak_trends.c: 365 84KB
+84KB (#3612 +3612)
create_id_from_object memleakserver.c: 170 25KB
+25KB (#1 +1)
create_id_from_classp memleakserver.c: 217 116KB

Finally, the print_memusage command can be used to display a memory map of various JVM subsystems and libraries that are loaded, including third-party libraries. This is done by passing the displayMap argument.

C:>jrcmd 5784 print_memusage displayMap
5784:
Total mapped 1311220KB +36168KB (reserved=1083664KB - 14720KB)
- Java heap 1048576KB (reserved=1002572KB - 16516KB)
- GC tables 35084KB
- Thread stacks 14592KB +4096KB (#threads=33 +10)
- Compiled code 5824KB +2048KB (used=5634KB +2069KB)
- Internal 1160KB
- OS 83180KB +2188KB
- Other 52660KB +4796KB
- JRockit malloc 30464KB +10688KB (malloced=29618KB +10047KB #302842 +100611)
- Native memory tracking 2112KB +1088KB (malloced=1035KB +582KB #672 +308)
- Java class data 37568KB +11264KB (malloced=37537KB +11243KB #45413 +14104)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CODE Compiled code rwx 0x0000000007ef0000 (128KB)
...
MSP JRockit malloc (179/266) rw 0x0000000008150000 (64KB)
THREAD Stack 6952 rwx 0x0000000008d80000 (12KB)
...
INT TLA memcache rw 0x000000000e330000 (64KB)
HEAP Java heap rw 0x0000000010040000 (46004KB)
HEAP Java heap reserved 0x0000000012d2d000.(1002572KB)
OS *awt.dll r x 0x000000006d0b1000
...
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Lowest accessible address 00010000
Highest accessible address 7FFEFFFF
Amount free virtual memory 786016KB
6 free vm areas in range 4KB - 8KB totalling > 24KB
7 free vm areas in range 8KB - 16KB totalling > 76KB
24 free vm areas in range 16KB - 32KB totalling >528KB
281 free vm areas in range 32KB - 64KB totalling > 15MB
3 free vm areas in range 64KB - 128KB totalling >236KB
9 free vm areas in range 128KB - 256KB totalling > 1MB
5 free vm areas in range 256KB - 512KB totalling > 1MB
7 free vm areas in range 512KB - 1MB totalling > 4MB
8 free vm areas in range 1MB - 2MB totalling > 11MB
2 free vm areas in range 2MB - 4MB totalling > 4MB
5 free vm areas in range 4MB - 8MB totalling > 30MB
1 free vm areas in range 8MB - 16MB totalling > 11MB
5 free vm areas in range 16MB - 32MB totalling >103MB
1 free vm areas in range 32MB - 64MB totalling > 51MB
1 free vm areas in range 64MB - 128MB totalling > 67MB
1 free vm areas in range 128MB - 256MB totalling >135MB
1 free vm areas in range 256MB - 512MB totalling >326MB

As can be seen in the previous example, the chunks of memory are categorized as:

This command shows how memory on the heap is used on a per-class basis. It can be used as a simple memory leak detection tool. Of course, the JRockit Mission Control Memory Leak Detector is far superior to this command, but it can still be useful when it, for some reason, is not feasible to use the Memory Leak Detector. There could, for instance, be a policy restriction which forbids the opening of an MLS server (see Chapter 10, The Memory Leak Detector).

The print_object_summary command prints a histogram of all the instances on the heap on a per-class basis, together with a differential value of how the memory usage has changed since the last invocation of the command.

C:>jrcmd 6328 print_object_summary
6328:
--------- Detailed Heap Statistics: ---------
22.1% 2697k 34813 +2697k [C
14.3% 1744k 373 +1744k [B
14.2% 1736k 3220 +1736k [Ljava/lang/Object;
11.8% 1443k 2177 +1443k [I
6.9% 839k 35833 +839k java/lang/String
5.6% 682k 6240 +682k java/lang/Class
2.6% 314k 13429 +314k java/util/HashMap$Entry
2.0% 242k 3218 +242k [Ljava/util/HashMap$Entry;
1.2% 149k 3185 +149k java/util/HashMap
1.0% 126k 5406 +126k java/util/Hashtable$Entry
0.9% 106k 2844 +106k [Ljava/lang/String;
0.8% 98k 1396 +98k java/lang/reflect/Field
0.5% 65k 844 +65k java/lang/reflect/Method
0.5% 64k 190 +64k [S
12192kB total ---
--------- End of Detailed Heap Statistics ---

The output contains one line per class that has instances on the heap.

The types are listed in the formal Java descriptor format. For more information on this format, please see The Java Language Specification on the Internet.

Normally, only types occupying more than 0.5 percent of the heap will be listed. To change this cutoff value, set the cutoff option to a value equal to the percentage value times 1,000. For example, to set it to 1.2 percent, set the cutoff to 1,200.

The print_object_summary command can do other tricks. The "points-to" parameters can be used to find out who is referring to all those char arrays in the previous example. A maximum of eight "points-to" parameters specifying different types are supported. They are somewhat unimaginatively named name1 through name8, and are called "points-to" as the type entered as argument will list the types having instances that in turn points to the argument type.

The following example lists all the types that have instances that point to char arrays and strings that occupy more than 0.1 percent of the heap:

C:>jrcmd 6352 print_object_summary cutoffpointsto=100 name1=[C name2=java/lang/String

The result would look something like this:

--------- Detailed Heap Statistics: ---------
42.0% 10622k 116820 +0k [C
11.3% 2851k 121648 +0k java/lang/String
6.0% 1520k 3676 +0k [Ljava/util/HashMap$Entry;
4.1% 1033k 18906 +12k org/eclipse/core/internal/ registry/ReferenceMap$SoftRef
3.5% 890k 38001 +0k java/util/HashMap$Entry
3.2% 800k 7323 +0k java/lang/Class
3.0% 747k 19820 +0k [Ljava/lang/String;
2.9% 741k 10063 +0k [I
2.9% 738k 15765 +0k org/eclipse/core/internal/ registry/ConfigurationElement
2.8% 699k 15469 +0k [Ljava/lang/Object;
1.1% 284k 262 +0k [B
1.0% 241k 4411 +1k org/eclipse/osgi/internal/ resolver/ExportPackageDescriptionImpl
0.7% 173k 7408 +0k org/osgi/framework/Version
0.7% 171k 3653 +0k java/util/HashMap
0.6% 148k 734 +0k [Ljava/util/Hashtable$Entry;
0.5% 129k 2 +0k [Lorg/eclipse/core/internal/ registry/ReferenceMap$IEntry;
25273kB total ---
[C is pointed to from:
99.6% 121713 java/lang/String
0.2% 270 [[C
java/lang/String is pointed to from:
37.2% 98288 [Ljava/lang/String;
15.6% 41274 java/util/HashMap$Entry
11.9% 31530 org/eclipse/core/internal/registry/ConfigurationElement
7.2% 19067 [Ljava/lang/Object;
--------- End of Detailed Heap Statistics ---

In the previous example, we can see that most of our char arrays are being referenced by strings, and that our strings are mostly being referenced by string arrays. No surprise there.

This command is usually employed to give an idea of the heap usage distribution. It can also be used to keep track of the types growing over time and for doing points-to analysis on such growing types to find memory leaks. However, if possible, the JRockit Mission Control Memory Leak Detector (Memleak) should be used for this kind of analysis, being both easier and more powerful to use.

See heap_diagnostics.

This command prints the initial properties from when the JVM was started, a set of JRockit specific VM properties, and the current state of the system properties. The output is in three sections, one for each property type. Each section has a header and a footer. Following is an example:

C:>jrcmd 6012 print_properties
6012:
=== Initial Java properties: ===
java.vm.specification.name=Java Virtual Machine Specification
java.vm.vendor.url.bug=http://edocs.bea.com/ jrockit/go2troubleshooting.html
java.home=D:demos_3.1jrmc_3.1jre
java.vm.vendor.url=http://www.bea.com/
java.vm.specification.version=1.0
file.encoding=Cp1252
java.vm.info=compiled mode
...
=== End Initial Java properties ===
=== VM properties: ===
jrockit.alloc.prefetch=true
jrockit.alloc.redoprefetch=true
jrockit.vm=D:demos_3.1jrmc_3.1jreinjrockitjvm.dll
jrockit.alloc.pfd=448
jrockit.alloc.pfl=64
jrockit.alloc.cs=512
jrockit.vm.dir=D:demos_3.1jrmc_3.1jreinjrockit
jrockit.alloc.cleartype=0
=== End VM properties ===
=== Current Java properties: ===
java.vm.vendor.url.bug=http://edocs.bea.com/ jrockit/go2troubleshooting.html
java.runtime.name=Java(TM) 2 Runtime Environment, Standard Edition
sun.boot.library.path=D:demos_3.1jrmc_3.1jrein
java.vm.version=R27.6.3-40_o-112056-1.5.0_17-20090318-2104-windows-ia32
java.vm.vendor=BEA Systems, Inc.
java.vendor.url=http://www.bea.com/
path.separator=;
java.vm.name=BEA JRockit(R)
file.encoding.pkg=sun.io
user.country=SE
...
=== End Current Java properties ===

This is the default SIGQUIT handler. It prints the stack trace for all threads. There are many different tools in the market for analyzing such thread dumps, but the most powerful way to analyze thread latency and blocking behavior is to either use the Latency Analysis part of the JRockit Runtime Analyzer or JRockit Flight Recorder. Even the JRockit Management Console can be used for simple analysis and for discovering deadlocked threads and information about them. This was covered in the previous chapters.

For example:

C:>jrcmd 7420 print_threads
7420:
===== FULL THREAD DUMP ===============
Mon Sep 28 00:08:56 2009
Oracle JRockit(R) R28.0.0-547-121310-1.6.0_14-20090918-2121-windows-ia32
"Main Thread" id=1 idx=0x4 tid=7776 prio=6 alive, in native
at org/eclipse/swt/internal/win32/OS.WaitMessage()Z (Native Method)[optimized]
at org/eclipse/swt/widgets/Display.sleep(Display.java:4220)[inlined]
at org/eclipse/ui/application/WorkbenchAdvisor.eventLoopIdle (WorkbenchAdvisor.java:364)[optimized]
at org/eclipse/ui/internal/Workbench.runEventLoop(Workbench.java:2385)
at ...
-- end of trace
"State Data Manager" id=13 idx=0x38 tid=7596 prio=5 alive, sleeping, native_waiting, daemon
at java/lang/Thread.sleep(J)V(Native Method)[optimized]
at org/eclipse/osgi/internal/baseadaptor/ StateManager.run(StateManager.java:297)
at java/lang/Thread.run(Thread.java:619)
at jrockit/vm/RNI.c2java(IIIII)V(Native Method)[optimized]
-- end of trace
...
"JFR request timer" id=34 idx=0x84 tid=2624 prio=5 alive, waiting, native_blocked, daemon
-- Waiting for notification on: java/util/ TaskQueue@0x1202F238[fat lock]
at jrockit/vm/Threads.waitForNotifySignal (JLjava/lang/Object;)Z(Native Method)[optimized]
at java/lang/Object.wait(J)V(Native Method)
at java/lang/Object.wait(Object.java:485)
at java/util/TimerThread.mainLoop(Timer.java:483)
^-- Lock released while waiting: java/util/ TaskQueue@0x1202F238[fat lock]
at java/util/TimerThread.run(Timer.java:462)
at jrockit/vm/RNI.c2java(IIIII)V(Native Method)[optimized]
-- end of trace
===== END OF THREAD DUMP ===============

The default version of the command prints the normal thread stack dump, that is a stack dump with no native frames. To include native frames in the thread dumps, pass the argument nativestack=true. To include information about locks implemented by classes in the java.util.concurrent package, pass the argument concurrentlocks=true.

This command lists all the UTF-8 constants currently in the JVM, for example class names, method names and string constants.

The following example lists the URLs in the constant pool.

$ jrcmd 3824 print_utf8pool | grep http
"http://www.w3.org/TR/xinclude": refs=2, len=29
"http://apache.org/xml/properties/internal/ symbol-table": refs=12, len=54

refs is the number of references to the constant and len is the length of the constant in bytes.

The print_vm_state command outputs the state of the JVM in a format similar to the dump file that is normally emitted when a JRockit instance crashes.

For example:

C:>jrcmd 7420 print_vm_state
7420:
Uptime : 0 days, 02:35:53 on Tue Sep 22 19:14:39 2009
Version : Oracle JRockit(R) R28.0.0-547-121310 -1.6.0_14-20090918-2121-windows-ia32
CPU : Intel Core 2 SSE SSE2 SSE3 SSSE3 SSE4.1 Core Intel64
Number CPUs : 2
Tot Phys Mem : 3706712064 (3534 MB)
OS version : Microsoft Windows Vista version 6.0 Service Pack 2 (Build 6002) (32-bit)
Thread System: Windows Threads
Java locking : Lazy unlocking enabled (class banning) (transfer banning)
State : JVM is running
Command Line : -Denv.class.path=.;C:Program Files Javajre6libextQTJava.zip -Dapplication.home=C:jrockitsR28.0.0_R28.0.0-547_1.6.0 -client - -XX:UnlockInternalVMOptions=true -Dsun.java.launcher= SUN_STANDARD com.jrockit.mc.rcp.start.MCMain
java.home : C:jrockitsR28.0.0_R28.0.0-547_1.6.0jre
j.class.path : C:jrockitsR28.0.0_R28.0.0- 547_1.6.0/missioncontrol/mc.jar
j.lib.path : C:jrockitsR28.0.0_R28.0.0-
...
StackOverFlow: 0 StackOverFlowErrors have occured
OutOfMemory : 0 OutOfMemoryErrors have occured
C Heap : Good; no memory allocations have failed
GC Strategy : Mode: pausetime, with strategy: singleconcon (basic strategy: singleconcon)
GC Status : OC is not running. Last finished OC was OC#369.
Heap : 0x10040000 - 0x17207000 (Size: 113 MB)
Compaction : (no compaction area)
CompRefs : References are 32-bit.
Loaded modules:
0000000000400000-000000000043afff C:jrockits R28.0.0_R28.0.0-547_1.6.0injrmc.exe
0000000077d30000-0000000077e56fff C:Windows system32
tdll.dll
00000000763f0000-00000000764cbfff C:Windowssystem32kernel32.dll
0000000077a30000-0000000077accfff C:Windowssystem32USER32.dll
0000000077400000-000000007744afff C:Windowssystem32GDI32.dll
0000000077ea0000-0000000077f65fff C:Windowssystem32ADVAPI32.dll
...
00000000764e0000-00000000765a2fff C:Windowssystem32RPCRT4.dll
000000006d3e0000-000000006d3fefff C:jrockits R28.0.0_R28.0.0-547_1.6.0jreinjava.dll

The dump contains diagnostic information about the state of the JVM, such as version information, locking paradigm, thread system, various paths, and the addresses of the loaded modules and libraries.

See heap_diagnostics.

As described in the code generation chapter, directive files can be used to start the JVM with a set of directives to the JVM optimization manager. The directive files can also be applied at run time by issuing the run_optfile diagnostic command. The command takes a single argument, filename—the file name of the directive file to be loaded. The directive file format for R27 differs from the one in R28. The R27 format is undocumented, and the only use case scenario where you are likely to encounter the run_optfile command in R27 is in interaction with JRockit support.

The R28 version of run_optfile for R28 can take several arguments. The most important one is the filename argument that specifies a directive file for the JVM as in R27. The directive file format for R28 is undocumented and subject to change without notice. Some limited examples of how to use directive files are given in Chapter 2, but this should by no means be considered complete.

The run_optfile command can also be used to re-compile selected methods with a given compilation strategy.

The following example will re-generate the java.util.ArrayList.get method using the optimized code generation strategy:

C:>jrcmd 7736 run_optfile method=java.util.ArrayList.get* strategy=opt disass=false

This command forces the JVM to execute a call to java.lang.System.runFinalization(), that is, hints to the runtime that any available finalizers should be run.

This command forces a full garbage collection.

Forcing a garbage collection is very rarely necessary. The JVM is good at deciding when to garbage collect. If the user interferes, the most probable result is a performance penalty. There are, however, rare cases when explicitly invoking the garbage collector may be helpful. Such cases may, for example, include using verbose GC logs to look at memory usage or live set usage, and not wanting to wait for a GC to occur.

If executed with no arguments, the runsystemgc command defaults to performing only a nursery collection. No compaction of the heap will take place.

To do a full garbage collection, the full argument needs to be set to true, as shown in the following example. When forcing a full garbage collection, an exceptional compaction will take place, which means that the entire heap will be compacted.

C:>jrcmd 4748 runsystemgc full=true
4748:

The runsystemgc command does not return any result.

This command sets an individual VM flag. It takes the name of the VM flag and its new value.

For example:

C:>jrcmd 7772 set_vmflag flag=DumpOnCrash value=false
7772:

Upon successful completion, the command does not return any message. Only writeable VM flags can be changed this way. If an attempt to change the value of a read-only flag is made, an error message is returned. For example:

C:>jrcmd 7772 set_vmflag flag=DisableAttachMechanism value=true
7772:
Not a writeable flag "DisableAttachMechanism"

To set the value of a VM flag that is not writeable at runtime, use the -XX:<Flag>=<value> syntax when starting the JVM.

See list_vmflags.

The start_flightrecording command starts a JRockit Flight Recorder recording. It can be used to start a continuous recording, that is a recording with no end time, or a timed recording that lasts for a specific duration. The recording can be configured using a number of named templates located in the JROCKIT_HOME/jre/lib/jfr folder. The files are in JSON format and can be copied and altered to create new templates.

For example:

C:>jrcmd 7420 start_flightrecording name=MyRecording settings= jra.jfs duration=30s filename=my_recording.jfr.gz compress=true
7420:
Started recording 5

The previous example starts a recording using the jra.jfs template. The recording will last for 30 seconds, after which a file will be emitted to the JROCKIT_HOME directory, named my_recording.jfr.gz. The file will be gzip compressed.

Using the check_flightrecording command to check on the recording after it has started, should look something like this:

C:>jrcmd 7420 check_flightrecording
7420:
Recording : id=0 name="continuous" duration=0s (running)
Recording : id=5 name="MyRecording" duration=30s dest="my_recording.jfr.gz" compress=true (running)

Once the 30 seconds have passed, the state of the recording will go from running to stopped and the recording file will be emitted.

Some templates are meant to be additive, that is they contain settings that are supposed to be used in addition to one of the base templates. The only way to identify such a template is currently by looking at the comment at the top of the file. If it starts with "Additional settings", the file is meant to be used together with one of the base settings. For instance, using the default template with additional lock information would look like this:

C:>jrcmd 7420 start_flightrecording name=DefaultAndLocks settings=default.fls settings=lock.fls duration=30s filename=defaultAndLocks.jfr.gz compress=true

The simplest way of starting, configuring, and retrieving JRockit Flight Recorder (JFR) recordings for analysis is to use the JRockit Mission Control client. For more information on how to do this, please refer to Chapter 9, The Flight Recorder.

See check_flightrecording, dump_flightrecording, and stop_flightrecording

This command starts the external management agent without having to edit startup scripts and then restarting the JVM. It works almost exactly the same way as the -Xmanagement JVM parameters used to start up the management agent.

Starting up an application server and deploying a J2EE application can take a considerable amount of time. There is usually a warm-up period involved to get everything properly optimized. Once everything is up and running, it is usually very annoying to realize that the necessary flags to start up the management agent were forgotten in the startup script. If the server is running in production, the next opportunity to take the server offline to restart it with a modified set of startup parameters may be quite far away.

The following example starts up the external management agent on port 4711 with SSL and authentication turned off and autodiscovery (JDP) turned on. Note that for SSL and authentication to work properly with this command, the password.properties file and a key store must be set up in advance. Please see the document Monitoring and Management Using JMX Technology on the Oracle Sun Developer Network website.

C:>jrcmd 473528 start_management_server ssl=false authenticate=false port=4711 autodiscovery=true 2416:

If everything goes well, this command will produce no output.

See kill_management_server.

The simplest way of starting and retrieving JRockit Runtime Analyzer (JRA) recordings for analysis is to use the JRockit Mission Control client. For more information on how to do this, please see Chapter 8, The Runtime Analyzer.

Sometimes, however, using the JRockit Mission Control client may not be an option. The environment may not allow JMX connections, or perhaps a JDK 1.4 based version of JRockit is used. In those cases, the startjrarecording diagnostic command is very useful. The following example starts a JRA-recording on the JRockit process with PID 5516. The duration of the recording will be two minutes and it will start after an initial delay of 30 seconds.

When sampling an application that utilizes a large framework or runs in an enterprise container, such as WebLogic Server, call stack depths can be quite large. In such cases, increasing the trace depth is usually a good idea. The trace depth in the following example has been increased to 64.

The sampletime option denotes how often the threads should be sampled. As this is a relatively short recording, the sample time has been compressed to every five milliseconds. The latency recording has been turned on to provide latency events.

C:>jrcmd 5516 startjrarecording filename=C:myrecording.jra recordingtime=120 delay=30 tracedepth=64 sampletime=5 latency=true
5516:
JRA recording started.

When the recording command has been sent, the JVM upon which the recording has been started should print something like the following to the console (stdout):

[INFO ][jra ] Delaying JRA recording for 30 seconds.
[INFO ][jra ] Starting JRA recording with these options:
filename=D:myrecording.jra, recordingtime=120s, methodsampling=1, gcsampling=1, heapstats=1, nativesamples=0, methodtraces=1, sampletime=5, zip=1, hwsampling=0 delay=30s, tracedepth=64 threaddump=1, threaddumpinterval=0s, latency=1, latencythreshold=20ms, cpusamples=1, cpusampleinterval=1s

Once the recording is done, it should print something similar to this:

[INFO ][jra ] Zipped the recording file.
[INFO ][jra ] Finished recording. Results written to C:myrecording.jra.

See checkjrarecording and stopjrarecording.

This command stops an ongoing JRockit Flight Recorder recording. The recording to stop can either be identified by name (name) or ID (recording).

For example:

C:>jrcmd 7420 stop_flightrecording recording=10
7420:

By default, the data will be saved to file when the recording is stopped. If the data is unwanted, pass the argument discard=true. The stop_flightrecording command will remove the recording from the listed recordings in check_flightrecording. So, the command can be used to clean out information about old recordings that are no longer of interest.

See check_flightrecording, dump_flightrecording, start_flightrecording.

This command prints a timestamp for a JVM and displays how long it has been running.

C:>jrcmd 6012 print_properties
6012:
==== Timestamp ==== uptime: 0 days, 00:04:39 time: Sun Jan 24 15:47:42 2010

This is a command for controlling the logging for the different logging modules in JRockit. The command can be used to change the logging level for a specific module, to redirect the output stream of the logger and to decorate the logging output. Running the verbosity command without arguments will list all the available logging modules with their current status.

C:demos_3.1>jrcmd 4504 verbosity
4504:
Current logstatus:
jrockit : level=WARN, decorations=201, sanity=NONE
memory (gc) : level=WARN, decorations=201, sanity=NONE
nursery (yc) : level=WARN, decorations=201, sanity=NONE
model : level=WARN, decorations=201, sanity=NONE
devirtual : level=WARN, decorations=201, sanity=NONE
codegen (code) : level=WARN, decorations=201, sanity=NONE
native (jni) : level=WARN, decorations=201, sanity=NONE
thread : level=WARN, decorations=201, sanity=NONE
opt : level=WARN, decorations=201, sanity=NONE

The first word on a line is the module name. The word in parenthesis after the module name, if there is one, is an alias that can also be used to refer to the module.

The following example shows how to enable verbose logging for the code generator in a similar fashion as described at the end of Chapter 2. This is equivalent to the output generated by starting the JVM with the flag -Xverbose:codegen.

C:>jrcmd 5556 verbosity set=codegen=INFO
5556:
Current logstatus:
jrockit : level=WARN, decorations=201, sanity=NONE
memory (gc) : level=WARN, decorations=201, sanity=NONE
nursery (yc) : level=WARN, decorations=201, sanity=NONE
model : level=WARN, decorations=201, sanity=NONE
devirtual : level=WARN, decorations=201, sanity=NONE
codegen (code) : level=INFO, decorations=201, sanity=NONE

As can be seen from the previous example, verbosity responds by listing the new log status.

The verbosity command can also be used to do exception profiling. Exception profiling is used to find out where the exceptions in an application occur.

Prior to the R28 version of JRockit and the exception profiling capabilities of the Flight Recorder, logging was the only possible, if somewhat tedious, way of doing exception profiling. As can be realized, this is just a somewhat more flexible way of running JRockit with -Xverbose:exceptions as described in Chapter 5.

The following example shows how to enable and disable exception profiling. It also shows how to use decorations. Leaving decorations empty will default to decorating the output with timestamp, module, and PID.

C:>jrcmd 6064 verbosity set=exceptions=info decorations=module
6064:
Current logstatus:

The resulting log for the JRockit process on which the diagnostic command is executed will contain an entry for every exception thrown. The example simply throws an ExceptionThrowerException every now and then with the message "Throw me!".

[excepti] ExceptionThrowerException: Throw me!
[excepti] ExceptionThrowerException: Throw me!

JRockit can also display the stack traces for thrown exceptions. Simply set the logging level to debug as shown in the following command-line execution:

D:>jrcmd 6064 verbosity set=exceptions=debug decorations=module
6064:
Current logstatus:

This will result in each exception line being followed by the stack trace showing exactly where the exception was thrown. This is the same behavior as is achieved by running JRockit with -Xverbose:exceptions=debug.

[excepti] ExceptionThrowerException: Throw me!
at jrockit/vm/Reflect.fillInStackTrace0 (Ljava/lang/Throwable;)V(Native Method)
at java/lang/Throwable.fillInStackTrace() Ljava/lang/Throwable;(Native Method)
at java/lang/Throwable.<init>(Throwable.java:196)
at java/lang/Exception.<init>(Exception.java:41)
at ExceptionThrowerException.<init>(ExceptionThrowerException.java:5)
at ExceptionThrower.throwMe(ExceptionThrower.java:24)
at ExceptionThrower.doStuff(ExceptionThrower.java:20)
at ExceptionThrower.loop(ExceptionThrower.java:11)
at ExceptionThrower.main(ExceptionThrower.java:4)
at jrockit/vm/RNI.c2java(IIIII)V(Native Method) --- End of stack trace

This can be done at runtime, even in production systems. If log level is reverted to its original form after the analysis is complete, no overhead will remain.

This command is quite useful when there is a need to find out what exact version of JRockit an application is running on, without having to restart it. When, for example, the JRockit JVM has been started as a service, and no console is available, this command is probably one of the easiest ways to find out the version number. The version command takes no arguments.

C:>%JAVA_HOME%injrcmd 2416 version 2416: BEA JRockit(R) (build R27.6.2-20_o-108500-1.6.0_05- 20090120-1116-windows-ia32, compiled mode)