Understanding YGC (Young Generation Garbage Collection) Latency: Key Phases and Optimization Strategies

YGC Latency Overview

The YGC latency problem mainly concentrates on the time spent in several key phases: live object scanning and marking, copying surviving objects to the survivor (S) region and promotion to the old generation, waiting for all threads to reach a safe point, GC log output, and operating‑system activities such as swapping.

1. Waiting for Threads to Reach a Safe Point

When a GC event occurs, most collectors (Serial, ParNew, Parallel Scavenge, Parallel Old, Serial Old) pause all application threads (STW). The JVM stops the world at a safe point —a location where the program can safely be paused, such as method return, loop exit, or exception throw.

If the spin‑time before reaching a safe point looks abnormal, inspect the code for large loops or other constructs that prevent threads from arriving quickly.

Additional events that can trigger a safe point (e.g., deoptimization, biased locking revocation) are also worth a separate discussion.

2. Live Object Scanning and Marking

After the program reaches a safe point, the JVM marks root objects and performs reachability analysis.

2.1 Thread‑Stack Object References

Two concepts are essential here: OopMap and RememberedSet . To avoid a full‑stack scan, the JVM maintains an OopMap that records where object references reside on each thread stack. At a safe point the OopMap is updated, then traversed, while the RememberedSet assists the reachability analysis.

This space‑for‑time trade‑off reduces scanning cost but does not eliminate the overhead of marking large numbers of live objects.

For example, a system with thousands of active business threads can cause significant OopMap traversal time.

Similarly, queries without proper limits may load massive data into memory, increasing GC time and even causing OOM.

2.2 Excessive Local Cache Objects

Objects that survive long enough are promoted to the old generation. When many locally cached objects are created, they are later scanned via the card table during YGC, adding to the marking time. Evaluating cache strategies or using off‑heap caches can mitigate this impact.

2.3 System Class Loader Loading Too Many Objects

Frequent creation of XStream instances (e.g., for XML parsing) leads to new class loaders. Each class loader registers its classes in the SystemDictionary, increasing the number of live Klass objects and prolonging the marking phase.

Since XStream is thread‑safe, it is advisable to reuse a single instance rather than creating one per deserialization.

2.4 JNI, Monitor, Finalizable, etc.

No concrete examples were encountered for these factors, but they may become relevant in specific workloads.

3. Live Object Copy

An illustrative example shows how the size of the Eden region and the amount of newly allocated objects affect the copy phase duration. Monitoring object allocation sizes and tuning Eden/Survivor sizes according to concurrency levels helps keep copy time low.

4. GC Log Output

GC logging, though often overlooked, contributes to STW time because the JVM writes log entries while all application threads are paused. If the underlying I/O subsystem is busy, log writing can become a noticeable delay.

A practical mitigation is to direct GC logs to a tmpfs mount (e.g., -Xloggc:/tmpfs/gc.log ), eliminating disk I/O latency.

Reference: “Backend I/O exceptions causing GC anomalies” – https://www.pianshen.com/article/5926239581/

Conclusion

YGC latency can arise from many sources, but they all revolve around a few core stages. By understanding and analyzing these stages—safe‑point pauses, live object scanning/marking, copying, logging, and OS activity—developers can systematically diagnose and reduce YGC pause times.