javagc (forcibly perform GC)

Format

javagc [-i|-f] [-v] [-s] [-force] [-ehgc] -p process-ID

To Page Top

Function

This command performs Full GC for a specific Java process (the process specified by process-ID) in the event of a memory leak or system failure and for the purpose of application debugging. The user can execute this command at any time of their choice. This command can also release Explicit memory blocks when performing Full GC.

The SIGQUIT signal is used for communicating with a Java process. When the command is executed, requests user to check the process contents of the command. When the response is n (do not generate, execute, or send), the command does not execute the process contents of the command (the return value is 1). You can omit this configuration step by specifying the -f option.

If the specified Java process is already performing Copy GC or Full GC triggered by a non-critical event, the command starts processing after the GC is completed.

To Page Top

Arguments

-i

Ask the user to check the following process contents:

• Whether to perform GC for the specified process (in Windows only)

• Whether to execute the Explicit memory block release for the process given in process-ID

• Whether to send the SIGQUIT signal in order to perform GC (in UNIX only)

A specification of the -f option before the -i option is ignored.

-f

Does not ask the user to check the following process contents:

• Whether to perform GC for the specified process (in Windows only)

• Whether to execute the Explicit memory block release

• Whether to send the SIGQUIT signal in order to perform GC (in UNIX only)

A specification of the -i option before the -f option is ignored.

-v

If the -XX:+HitachiVerboseGC option is not specified, creates a Java VM log file according to the Java VM log file creation rules and outputs the extended verbosegc information.

In such cases, output the extended verbosegc information of the contents, also with the effect of the following option values:

• -XX:+HitachiVerboseGCPrintDate

• -XX:+HitachiVerboseGCPrintCause

• -XX:+HitachiVerboseGCCpuTime

• -XX:+HitachiCommaVerboseGC

-s

Outputs the extended verbosegc information to the standard output.

In such cases, -s outputs the extended verbosegc information of the contents in which the following option values are also reflected:

• -XX:+HitachiVerboseGCPrintDate

• -XX:+HitachiVerboseGCPrintCause

• -XX:+HitachiVerboseGCCpuTime

• -XX:+HitachiCommaVerboseGC

-force

If this option is specified, the command forcibly performs GC (and releases Explicit memory blocks) for the Java process specified for the -p option without confirming that the /tmp/hsperfdata_user-name/process-ID file has already been created by the Java process.

Note that this option is for UNIX.

-ehgc

If this option is specified, the command releases Explicit memory blocks when performing Full GC for the specified Java process. For the Explicit memory block release, see 7.9 Releasing Explicit memory blocks by using the javagc command in the uCosminexus Application Server Expansion Guide.

-p process-ID

Specifies the ID of the process for which you want to perform Full GC (and release Explicit memory blocks).

For the Hitachi-specific Java VM extension options, see the following locations:

• 14.1 List of Hitachi-specific JavaVM extension options in the uCosminexus Application Server Virtual System Setup and Operation Guide.

• 14.2 Details of JavaVM extension options in the uCosminexus Application Server Definition Reference Guide.

To Page Top

Return values

0:

The command terminated normally.

1:

The command terminated abnormally.

2:

A report on completion of GC was not returned within a certain length of time.

To Page Top

Input examples

1. Execution of the javagc command, with the -i option specified:

   javagc -i -v -p 8326

2. In Windows, the command asks the user whether to perform GC. In UNIX, the command asks the user whether the target process ID is correct.

   • In Windows:

     Force VM to execute GC ? (y/n)

   • IN UNIX:

     send SIGQUIT to 8326:?(y/n)

3. In Windows, the user enters y to perform GC (or n not to perform GC). In UNIX, the user enters y to send the SIGQUIT signal (or n not to send the signal).

   • In Windows:

     Force VM to execute GC ? (y/n)y

   • In UNIX:

     send SIGQUIT to 8326:?(y/n)y

To Page Top

Output example

 [VGC]<Wed Mar 17 00:42:30 2004>(Skip Full:0,Copy:0)[Full GC 149K->149K(1984K), 0.0786038 secs][DefNew::Eden: 264K->0K(512K)][DefNew::Survivor: 0K->63K(64K)][Tenured: 85K->149K(1408K)][Metaspace: 3634K(4492K, 4492K)->3634K(4492K, 4492K)][class space: 356K(388K, 388K)->356K(388K, 388K)][cause:JavaGC Command]

To Page Top

Output messages

To Page Top

Notes

• Two or more instances of the javagc command cannot be executed for the same Java process. If GC performed by the javagc command is in progress, wait until the processing ends, and then execute the javagc command. You can confirm that the previous GC has ended in the Java VM log file. If the previous GC has ended, the string JavaGC Command has been output as the cause of GC by the extended verbosegc function.

• In Windows, even the users other than the java process owner indicated by the process ID specified in the arguments can execute the javagc command.

• In UNIX, the javagc command sends the SIGQUIT signal to the specified process ID. If you specify a process ID of a non-java process by mistake, the other programs might stop.

• In UNIX, the javagc command uses the /tmp/hsperfdata_user-name/process-ID file at runtime. This file needs to exist in order for the javagc command to request GC. However, if the -force option is specified, the command forcibly performs GC for the Java process specified for the -p option without confirming that the /tmp/hsperfdata_user-name/process-ID file exists.

To Page Top