find which type of garbage collector is running

Post JSE 5 ergonomics is intended to automatically select the appropriate type of garbage collector for you (among other things).

I would like to know if there is any way to confirm/know the type of garbage collector and performance goals chosen/current set by the JVM ergonomics.

java -XX:+PrintCommandLineFlags -version

will show you the default garbage collector. I have also found the following page useful which details the default garbage collector for various operating systems.

(For Java <= 8)

This command print the GC type of a running JVM:

jmap -heap <pid> | grep GC

For modern computer (multiple cpus, big memory), JVM will detect it as server machine, and use Parallel GC by default, unless you specify which gc to use via JVM flags explicitly.

e.g

jmap -heap 26806 | grep GC

Output:

> Parallel GC with 8 thread(s)

---

@Update - for Java 9+

(Thanks to @JakeRobb's comment.)

Since Java 9, there are 2 changes relevant to this question:

• Need to use jhsdb to attach to a java process or launch a debugger.
  Refer: jhsdb
• The default gc is changed to G1.

Command format:

jhsdb jmap --heap --pid <pid> | grep GC

e.g

jhsdb jmap --heap --pid 17573 | grep GC

Output:

> Garbage-First (G1) GC with 8 thread(s)

import java.lang.management.GarbageCollectorMXBean;
import java.lang.management.ManagementFactory;
import java.util.List;

public class GCInformation {

    public static void main(String[] args) {
            try {
                    List<GarbageCollectorMXBean> gcMxBeans = ManagementFactory.getGarbageCollectorMXBeans();

                    for (GarbageCollectorMXBean gcMxBean : gcMxBeans) {
                            System.out.println(gcMxBean.getName());
                            System.out.println(gcMxBean.getObjectName());
                    }

            } catch (RuntimeException re) {
                    throw re;
            } catch (Exception exp) {
                    throw new RuntimeException(exp);
            }
    }
}

e.g. try following commands to know various GC Type

java -XX:+PrintCommandLineFlags  GCInformation
java -XX:+PrintCommandLineFlags -XX:+UseParallelGC GCInformation
java -XX:+PrintCommandLineFlags -XX:+UseConcMarkSweepGC -XX:+UseParNewGC GCInformation
java -XX:+PrintCommandLineFlags -XX:+UseConcMarkSweepGC -XX:-UseParNewGC GCInformation

Not a direct answer to your question, but I believe this is what you're looking for.

According to Java 6 documentation 1 and 2 (not just Java 5):

Reference 1 says:

> On server-class machines running the > server VM, the garbage collector (GC) > has changed from the previous serial > collector [...] to a parallel collector

Reference 2 says:

> Starting with J2SE 5.0, when an > application starts up, the launcher > can attempt to detect whether the > application is running on a > "server-class" machine and, if so, use > the Java HotSpot Server Virtual > Machine (server VM) instead of the > Java HotSpot Client Virtual Machine > (client VM).

Also, reference 2 says:

> Note: For Java SE 6, the definition of > a server-class machine is one with at > least 2 CPUs and at least 2GB of > physical memory.

From this information, you can know that if the box is a server (according to 2) then it will be using the parallel GC. You can also infer that it will not change GC during runtime.

You can probably find the right answer for non-server machines if you dig further into the documentation.

-XX:+PrintGC
-XX:+PrintGCDetails

This will print what GC is used. In my case it prints:

[GC (Allocation Failure) [PSYoungGen: 348192K->32K(348672K)] 356792K->8632K(1048064K), 0.0111518 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]

Which means that the Parallel Garbage collector is being used for the young generation. "Allocation Failure" means that garbage collection started because there were not enough space in young generation heap part.

You could use the following VM arguments with JDK 14,

-Xlog:gc -Xlog:gc*

The log will be:

[0.008s][info][gc,heap] Heap region size: 1M
[0.008s][info][gc,heap,coops] Heap address: 0x0000000700000000, size: 4096 MB, Compressed Oops mode: Zero based, Oop shift amount: 3
[0.011s][info][gc           ] Using G1
[0.011s][info][gc,cds       ] Mark closed archive regions in map: [0x00000007bff00000, 0x00000007bff7aff8]
[0.011s][info][gc,cds       ] Mark open archive regions in map: [0x00000007bfe00000, 0x00000007bfe50ff8]
[0.027s][info][gc           ] Periodic GC disabled

Use the GarbageCollectorMXBeans to obtain MemoryPoolMXBeans.

Here's some info about how to programmatically get GC info, but it looks like it may need the name of the GC beforehand. Troublesome.

Edit: try ManagementFactory.getGarbageCollectorMXBeans() and iterate through the returned list. One of these will be active.

To achieve performance goal you need to check with various GC algorithms.

Available Collector in Oracle JDK

-XX:+UseSerialGC

-XX:+UseParallelGC

-XX:+UseG1GC

-XX:+UseConcMarkSweepGC

-XX:UseZGC

Turning on GC Logging in Java 7 / 8

java -XX:+PrintGCDetails -XX:+PrintGCDateStamps - Xloggc: <file-path>

Turning on GC Logging in Java 9 and Up

java –Xlog:gc*:file=<file-path>:filecount=10,filesize=10M

Dynamically Turning on GC Logging in Java 9 and Up

jcmd <pid> VM.log what=gc output=<file-path>

Try GC Log analyzing tool for compare GC logs

GC Log Analyzer - http://www.gcloganalyzer.com

You can use -XX flag for JRE to choose the garbage collector of your choice.

Tuning Garbage Collection with the 5.0 Java TM Virtual Machine

Additionally, you can use JConsole to monitor garbage collection.