Java garbage collection due to Metadata GC Threshold when metaspace occupancy is less than its maximum capacity

Environment

• OpenJDK 1.8 u40+
• Oracle JDK 1.8 u40+

Issue

• A Metadata GC Threshold triggering a collection despite the GC logging showing plenty of available Metaspace. For example, in the following GC log entry the Metaspace occupancy is 256590K, and the Metaspace capacity is 1230848K:

  [Full GC (Metadata GC Threshold) 308976.826: [CMS: 50324K->50420K(1756416K), 0.2793245 secs] 296498K->50420K(2063104K), [Metaspace: 256590K->256590K(1230848K)], 0.2799017 secs]
  

Resolution

Increase MetaspaceSize to avoid hitting the "Metadata GC Threshold"
and/or provide more headroom for the metaspace to be collected more efficiently by a parallel or concurrent collector.

For the CMS collector, check that CMSClassUnloadingEnabled is not disabled with -XX:-CMSClassUnloadingEnabled, and check to make sure CMS cycles are running frequently to reclaim metaspace concurrently.

Root Cause

The metaspace occupancy has reached the threshold that triggers garbage collection ("Metadata GC Threshold").

The initial threshold is the determined by the MetaspaceSize setting. (e.g. -XX:MetaspaceSize=1024M) . After that, the JVM may adjust the threshold based on ergonomics.

When UseCompressedOops and UseCompressedClassesPointers (introduced JDK 1.8 u40) are enabled (default when MaxHeap < 32g), metaspace is the sum of two separate native memory spaces:

• class metadata
• compressed class pointers (CompressedClassSpaceSize)

The MetaspaceSize setting applies to the sum of the committed memory for both spaces.

Diagnostic Steps

Analyze gc logging and the MetaspaceSize setting.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.