Catalog
concept#Observability#Reliability#Runtime

Garbage Collection

Automatic reclamation of heap memory performed by the runtime.

Garbage Collection (GC) comprises strategies by managed runtimes to detect unreachable objects and reclaim their memory automatically.
Established
Medium

Classification

  • Medium
  • Technical
  • Architectural
  • Advanced

Technical context

APM/tracing (e.g., OpenTelemetry)Heap analyzers (MAT, VisualVM)Feature flags for collector switches

Principles & goals

Avoid manual memory managementPredictable latencyResource efficiency
Build
Domain

Use cases & scenarios

Compromises

  • Heaps sized too small cause frequent collections
  • Pause spikes may violate SLAs
  • Misconfigured logging introduces overhead
  • Set heap sizes explicitly instead of using defaults
  • Enable JSON-format GC logs for analysis
  • Monitor and reduce object allocation rate

I/O & resources

  • Heap sizing parameters (initial and maximum)
  • Collector and tuning parameters per runtime
  • Monitoring and profiling tools
  • Reclaimed heap memory
  • Stable latency profiles
  • GC telemetry for capacity planning

Description

Garbage Collection (GC) comprises strategies by managed runtimes to detect unreachable objects and reclaim their memory automatically. Common approaches include tracing collectors (mark-sweep, generational, incremental, concurrent) and reference counting with cycle detection. The goal is to avoid memory leaks, eliminate manual deallocation, and balance latency and throughput across varied workloads.

✔

  • Reduces memory leaks and double-free errors
  • Developers avoid explicit deallocation
  • Stable performance despite object churn

✖

  • Stop-the-world pauses can raise latency
  • Non-deterministic reclamation timing
  • Tuning effort depends on workload

  • Max GC pause

    Longest stop-the-world duration per collection.

  • Throughput (ops/s)

    Operations per second under steady GC load.

  • Heap utilization

    Heap occupancy before and after collections.

Generational GC in a web service

Default collector with short pauses for API workloads.

Concurrent collector for memory-heavy analytics

Very large heaps with pauses in low milliseconds.

Throughput-oriented collector in batch pipelines

Throughput prioritized over latency.

1

Analyze workload (latency vs throughput)

2

Select an appropriate collector (e.g., generational, concurrent, reference counting)

3

Set GC flags, instrument metrics, run load test

⚠️ Technical debt & bottlenecks

  • Outdated runtime version lacking modern collectors
  • No automated GC log analysis
  • Missing load tests for GC regressions
Long stop-the-world pausesFragmented heapExcessive object allocation
  • Region-based collector with a tiny heap on latency-critical services
  • Throughput-only collector for UI applications
  • Relying on aggressive finalizers instead of clear lifecycles
  • Pause spikes from full GC after allocation bursts
  • Accidental promotion of long object chains
  • Underestimated fragmentation with non-copying collectors
Understanding of heap and thread modelsReading and interpreting GC logsProfiling and leak diagnosis
Service level agreementsHeap size and object lifetimeWorkload pattern (interactive vs batch)
  • • Maximum pause time per SLA
  • • Limited CPU cores for GC threads
  • • Compatible runtime version