Wednesday Apr 22, 2015

Throughput collector and PrintTenuringDistribution option

This is going to be a very short blog post. The inspiration for this post is a customer report that the PrintTenuringDistribution option does not show age information with the throughput collector (Parallel or Parallel Old GC).

2.798: [GC
Desired survivor size 11534336 bytes, new threshold 7 (max 15)
[PSYoungGen: 67584K->9802K(78848K)] 67584K->9810K(254976K), 0.0467029 secs]
[Times: user=0.07 sys=0.02, real=0.05 secs]
3.604: [GC
Desired survivor size 11534336 bytes, new threshold 7 (max 15)
[PSYoungGen: 77386K->11156K(146432K)] 77394K->11236K(322560K), 0.0436806 secs]

Well, this is the expected behavior and is not a bug. Throughput collector does not use the age table like the other collectors do. And due to that reason, the age histogram information is not printed with the throughput collector. With the throughput collector, we can only see the desired survivor size, threshold age, and the maximum threshold age with PrintTenuringDistribution option.

Wednesday Mar 19, 2014

About G1 Garbage Collector, Permanent Generation and Metaspace

We received some questions around the G1 garbage collector and the use of Permanent Generation with it. There seems to be some confusion that the Hotspot JVM does not use permanent generation when G1 is used as the garbage collector. Here’s some clarification:

JDK 7: PermGen

Permanent Generation still exists in JDK 7 and its updates, and is used by all the garbage collectors. In JDK7, the effort to remove the permanent generation was started and some parts of the data residing in the permanent generation were moved to either the Java Heap or to the native heap. Permanent generation was not completely removed and it still exists in JDK 7 and its updates. Here's the list of things that were moved out of the permanent generation in JDK7:

  • Symbols were moved to the native heap

  • Interned strings were moved to the Java Heap

  • Class statics were moved to the Java Heap

JDK7: G1 and PermGen

With G1 collector, PermGen is collected only at a Full GC which is a stop-the-world (STW) GC. If G1 is running optimally then it does not do Full GCs. G1 invokes the Full GCs only when the PermGen is full or when the application does allocations faster than G1 can concurrently collect garbage.

With CMS garbage collector, we can use option -XX:+CMSClassUnloadingEnabled to collect PermGen space in the CMS concurrent cycle. There is no equivalent option for G1. G1 only collects PermGen during the Full stop-the-world GCs.

We can use options PermSize and MaxPermSize to tune the PermGen space size according to the application needs.

JDK8: PermGen

Permanent generation has been completely removed in JDK 8. This work has been done under the bug Options PermSize and MaxPermSize have also been removed in JDK 8.

Email to openjdk alias regarding the PermGen elimination project:

JDK8: Metaspace

In JDK 8, classes metadata is now stored in the native heap and this space is called Metaspace. There are some new flags added for Metaspace in JDK 8:

  • -XX:MetaspaceSize=<NNN> where <NNN> is the initial amount of space(the initial high-water-mark) allocated for class metadata (in bytes) that may induce a garbage collection to unload classes. The amount is approximate. After the high-water-mark is first reached, the next high-water-mark is managed by the garbage collector
  • -XX:MaxMetaspaceSize=<NNN> where <NNN> is the maximum amount of space to be allocated for class metadata (in bytes). This flag can be used to limit the amount of space allocated for class metadata. This value is approximate. By default there is no limit set.
  • -XX:MinMetaspaceFreeRatio=<NNN> where <NNN> is the minimum percentage of class metadata capacity free after a GC to avoid an increase in the amount of space (high-water-mark) allocated for class metadata that will induce a garbage collection.
  • -XX:MaxMetaspaceFreeRatio=<NNN> where <NNN> is the maximum percentage of class metadata capacity free after a GC to avoid a reduction in the amount of space (high-water-mark) allocated for class metadata that will induce a garbage collection.

By default class metadata allocation is only limited by the amount of available native memory. We can use the new option MaxMetaspaceSize to limit the amount of native memory used for the class metadata. It is analogous to MaxPermSize. A garbage collection is induced to collect the dead classloaders and classes when the class metadata usage reaches MetaspaceSize (12Mbytes on the 32bit client VM and 16Mbytes on the 32bit server VM with larger sizes on the 64bit VMs). Set MetaspaceSize to a higher value to delay the induced garbage collections. After an induced garbage collection, the class metadata usage needed to induce the next garbage collection may be increased.

Monday Jul 13, 2009

G1 Collector

In 6u14, a preliminary version of the new Garbage First (G1) garbage collector is included.

Garbage First, or G1, is a low pause, server style garbage collector targeted for multi-processors with large memories. G1's primary advantages over the Concurrent Mark-Sweep (CMS) collector include incremental compaction, better predictability and ease of use.

For using G1, need to specify following command line options:

-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC

The following options can be used to affect G1's behavior:

\* To set the max GC pause time goal in milliseconds that G1 will attempt to meet:


\* To set the time interval over which GC pauses totaling up to MaxGCPauseMillis may take place:


Monday May 21, 2007

Collector names for GarbageCollectorMXBean MXBean

While trying to use GarbageCollectorMXBean to obtain GC information about a running process, I had to look around to find out the correct name strings for various Garbage Collectors.

This is what I did to obtain an instance of GarbageCollectorMXBean:
  MBeanServer server = ManagementFactory.getPlatformMBeanServer();
  GarbageCollectorMXBean bean = ManagementFactory.newPlatformMXBeanProxy(server,
             GC_BEAN_NAME, GarbageCollectorMXBean.class);

where GC_BEAN_NAME is the ObjectName for uniquely identifying the MXBean for a garbage collector within an MBeanServer and it is of the form:
    java.lang:type=GarbageCollector,name=collector's name  

Now, what is the correct string for collector's name?

Here are the name strings for various collectors in VM:

You can run a simple java program with different collectors and using the below code snippet, can see the full object names of all the available GarbageCollectorMXBean MXBeans.
MBeanServer mbs = ManagementFactory.getPlatformMBeanServer();
Set names = mbs.queryNames(null, null);
System.out.println(names.toString().replace(", ",



« July 2016