Analyzing GC Slowdown Caused by SystemDictionary Growth in Java Applications Using XStream

Overview

This article discusses a GC issue observed in a demo program posted by a public account author, along with related problems where jstack and jmap cannot be used. The most common cause is that the user running these tools differs from the target process user, even if the tool is executed as root. The author also points out that using jmap -heap or -histo triggers the Serviceability Agent, which may hang the process if a bug prevents the detach action; the process can be identified in T state via top and resumed with kill -CONT <pid> .

Demo Analysis

The demo code is simple but special: replacing the XStream object with a plain Object eliminates the problem, indicating that the XStream constructor is the culprit. The constructor creates many objects, resulting in an XStream instance of roughly 12 MB. By gradually disabling parts of the constructor or using a different class loader (AppClassLoader), the issue disappears.

Class Loader Concepts

The article explains two important concepts: the initial class loader and the defining class loader . In a chain AClassLoader → BClassLoader → CClassLoader, A is the initial loader, C is the defining loader for a class loaded through the chain. The JVM records these relationships in a hashtable called SystemDictionary , keyed by the class loader and class name.

The separation allows the JVM to quickly locate already‑loaded classes: if the same initial loader requests a class again, the JVM can return the existing Klass without delegating further.

Does the Demo's Class Loader Load Classes?

The demo creates a CompositeClassLoader . By setting a breakpoint on its loadClass method, a stack trace shows that actual loading is performed by AppClassLoader . Consequently, CompositeClassLoader becomes the initial loader while AppClassLoader is the defining loader, and both entries are stored in SystemDictionary . Repeatedly creating XStream objects continuously inserts new entries, inflating SystemDictionary . This growth makes Young Generation GC (YGC) scan a larger structure, increasing GC pause times. The hypothesis is verified with the perf tool, which shows that functions operating on SystemDictionary dominate CPU usage during GC.

Why SystemDictionary Affects the GC Process

When a class is loaded, its Klass object becomes a GC root because instances of that class reference it. Therefore, SystemDictionary is scanned in every GC cycle. The VM code path SH_PS_SystemDictionary_oops_do performs this scan. Although YGC does not unload classes, enabling class unloading (e.g., CMSClassUnloadingEnabled ) allows Full GC or CMS GC to clean up the dictionary. Running jmap -dump:live,format=b,file=heap.bin <pid> forces a full GC that clears the dictionary, instantly reducing YGC time, which then gradually rises again as the dictionary expands.

Modifying the VM to Verify the Claim

Since HotSpot does not provide per‑task timing for YGC, the author added instrumentation to the VM source around the SH_PS_SystemDictionary_oops_do task. After recompiling and rerunning the demo, the measured YGC pause times correlated directly with the time spent in SystemDictionary_oops_do , confirming that the dictionary scan is the primary cause of the observed GC slowdown.