Junior Level

Shenandoah GC — ultra-low latency garbage collector, alternative to ZGC.

Main feature: Pauses < 1 ms, like ZGC, but developed by Red Hat for OpenJDK.

When to use:

• Need low latency
• Using OpenJDK/Alpine Linux
• ZGC not available

---

Middle Level

Key Innovation

Concurrent compaction (Evacuation):
  → Objects moved WITHOUT stopping the application
  → Unlike G1 (Evacuation = STW)

Load Reference Barriers

On reference read:
  → Check if object moved
  → If moved → return new address

→ Cheaper than Brooks Pointers (old approach)

Barrier — a check inserted by JIT on every memory operation. Load Reference Barrier: on reference read, checks if object was moved. If moved — automatically fixes the pointer.

Lifecycle

1. Init Mark (STW) — Roots scanning
2. Concurrent Marking — background marking
3. Final Mark (STW) — finalization
4. Concurrent Evacuation — object relocation
5. Update References (STW) — reference update

Shenandoah vs ZGC

Criterion	Shenandoah	ZGC
Developer	Red Hat	Oracle
Barriers	Load Reference	Load + Colored Pointers
Generations	Yes (Java 21+)	Yes (Java 21+)

Shenandoah vs ZGC: both concurrent, but different mechanisms. ZGC uses Colored Pointers (metadata in pointers) and Load Barriers. Shenandoah uses Load Reference Barriers — barrier on REFERENCE READ that automatically fixes pointer if object moved.

---

Senior Level

Degenerated GC

Evacuation Failure → Degenerated GC (STW)
  → If not helped → Full GC

Causes:
  - High Allocation Rate
  - Small Heap

Solution: increase -Xmx or ConcGCThreads

CPU Overhead

Load Barriers + Concurrent Threads
  → overhead 5-15% CPU
  → Background GC threads consume cores

Generational Shenandoah

Java 21+: generational split
  → -50% overhead
  → More efficient young object collection

Best Practices

1. Alpine Linux (musl libc): Shenandoah is more stable than ZGC on musl. ZGC historically had issues with musl libc.
2. Adaptive heuristics by default
3. Increase ConcGCThreads on Allocation Stall
4. Monitor Degenerated GC in logs
5. Java 21+ → test Generational mode

Senior Summary

• Shenandoah = concurrent compaction
• Load Reference Barriers = check on read
• Degenerated GC = fallback on failure
• Generational (Java 21+) = -50% overhead
• Alternative to ZGC for OpenJDK

---

Interview Cheat Sheet

Must know:

• Shenandoah: pauses < 1 ms, concurrent compaction (Evacuation WITHOUT STW); developed by Red Hat for OpenJDK
• Load Reference Barriers: on reference read, check if object moved; if moved — automatic pointer fix
• Lifecycle: Init Mark (STW) → Concurrent Marking → Final Mark (STW) → Concurrent Evacuation → Update References (STW)
• Degenerated GC: Evacuation Failure → STW attempt to recover; if failed → Full GC
• Generational Shenandoah (Java 21+): generational split → -50% overhead
• Shenandoah is more stable than ZGC on Alpine Linux (musl libc); ZGC historically had issues with musl

Common follow-up questions:

• How does Shenandoah differ from ZGC? — ZGC uses Colored Pointers + Load Barriers; Shenandoah uses Load Reference Barriers (check only on reference read, cheaper)
• What is Degenerated GC? — Fallback on Evacuation Failure: STW attempt to complete collection; if failed → Full GC
• When to choose Shenandoah over ZGC? — Alpine Linux (musl), OpenJDK without ZGC, or if Load Reference Barriers are cheaper for your workload
• What are Adaptive Heuristics? — Shenandoah automatically tunes GC parameters based on application behavior; usually doesn’t require manual tuning

Red flags (DO NOT say):

• “Shenandoah uses Colored Pointers” — that’s ZGC; Shenandoah uses Load Reference Barriers
• “Shenandoah and ZGC are the same” — different mechanisms: ZGC = Colored Pointers, Shenandoah = Load Reference Barriers
• “Shenandoah has no generations” — since Java 21, Generational Shenandoah exists

Related topics:

• [[14. What is ZGC]]
• [[12. What GC algorithms exist]]
• [[16. What is stop-the-world]]
• [[17. Which GCs minimize stop-the-world pauses]]
• [[13. What is G1 GC]]