HP (Hewlett-Packard) 5992-1918 Manual Do Utilizador

In general, all errors detected by -Xcheck:jni are fatal; the error is printed and the Java VM
is aborted. One exception to this is a non-fatal warning that is printed when a JNI call is made
within a JNI critical region. This is the warning that is displayed when this happens:

Warning: Calling other JNI functions in the scope of 
Get/ReleasePrimitiveArrayCritical or Get/ReleaseStringCritical

A JNI critical region arises when native code uses the JNI GetPrimitiveArrayCritical()
or GetStringCritical() functions to obtain a reference to an array or string in the Java heap.
The reference is held until the native code calls the corresponding release function. The time
between the get and release is called a JNI critical section, and during that time the Java VM
cannot reach a state that allows garbage collection to occur. The general recommendation is that
other JNI functions should not be used when in a JNI critical section, and in particular any JNI
function that blocks could potentially cause a deadlock. The warning printed by -Xcheck:jni
is an indication of a potential issue; it does not always indicate an application bug.

1.25 -Xverbosegc

The -Xverbosegc option prints out detailed information about the Java heap before and after
garbage collection. The syntax is:

-Xverbosegc [:help] | [0 | 1] [:file = [stdout | stderr | <filename>]]

The “:help” option prints a description of the verbosegc output format.

The “0 | 1” option controls the printing of help information. Specifying value “0” will cause
the heap information to be printed after every Old Generation GC or Full GC. Specifying value
“1” (the default) will cause the heap information to be printed after every GC.

The “file = [stdout | stderr | <filename>]” option specifies the output file. The
default is stderr, which directs the output to the standard error stream. Alternative choices for
the output file are stdout and a user-specified filename.

-Xverbosegc

sends log information to stderr by default. It is preferable to send the output

to a specific logfile instead since runtime errors may also send output to stderr. The following
command line sends -Xverbosegc output to a text file named yourApp_pid<pid>.vgc:

java -Xverbosegc:file=yourApp_pid<pid>.vgc yourApp

At every garbage collection 20 fields are printed as follows:

GC: %1 %2 %3 %4 %5 %6 %7 %8 %9 %10 %11 %12 %13 %14 %15 %16 %17 %18 %19 %20 

The following table contains brief descriptions of these 20 fields:

Table 1-15 Garbage Collection Field Information

Information in Field

Field

Type of GC:
• 1: Scavenge (GC of New Generation only)
• 2: Old Generation GC or a Full GC
• 3: Complete background CMS GC
• 4: Incomplete background CMS GC
• 11: Ongoing CMS GC

1

Additional information based on GC type in field 1.

2

Program time at the beginning of the GC, in seconds.

3

GC invocation. Counts of background CMS GCs and other GCs are maintained separately.

4

Size of the object allocation request that forced the GC, in bytes.

5

Tenuring threshold—determines how long the newborn object remains in the New Generation.

6

Eden Sub-space (within the New Generation) occupied before GC.

7

46

Diagnostic and Monitoring Tools and Options