Java Troubleshooting Guide for HP-UX Systems

• The JNI environment for the wrong thread is used
• An invalid JNI reference is used
• A reference to a nonarray type is provided to a function that requires an array type
• A nonstatic field ID is provided to a function that expects a static field ID
• A JNI call is made with an exception pending
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 nonfatal 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” causes the
heap information to be printed after every Old Generation GC or Full GC. Specifying value “1”
(the default) causes 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 because 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 FieldField
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
46 Diagnostic and Monitoring Tools and Options