agent's memory leak alert fired on JVM heap growth that was just the heap filling to -Xmx

agent's memory leak alert fired on JVM heap growth that was just the heap filling to -Xmx

TL;DR

A JVM grows its heap toward -Xmx as needed; that is normal, not a leak. A leak is growth after full GCs that never reclaims, or old-gen growth that never plateaus. Alert on post-GC old-gen trends, not on heap size. The alert fired on physics, not a bug.

agent's memory leak alert fired on JVM heap growth that was just the heap filling to -Xmx

Steps

1. Check the GC logs: after a full GC, does old-gen usage return to a stable level? Expected: If yes, there is no leak; the heap is just filling its allowed space.

2. Plot old-gen after full GCs over days, not heap committed. Expected: A real leak shows a rising floor; normal fill shows a flat floor under a rising ceiling.

3. Retune the alert: fire on the post-GC old-gen trend crossing a threshold, with a minimum observation window. Expected: The alert stops firing on healthy growth.

4. Size -Xmx deliberately: 3-4x the steady-state live set gives headroom without hiding leaks for months. Expected: The heap has room to breathe and leaks still surface.

5. Document the expected sawtooth so the next on-call does not page on it. Expected: The pattern is recognized, not alarming.

When to use

• a leak alert fires on a healthy JVM
• heap grows toward -Xmx and stabilizes
• post-GC old-gen is flat

When not to use

• post-GC old-gen climbs steadily (that is a real leak)
• the JVM actually OOMs (investigate, do not just retune the alert)
• using a collector where old-gen is not the right signal (ZGC/Shenandoah need different metrics)

Tool compatibility

• HotSpot JVM
• GC logging

Variant phrasings

• "JVM heap growth to Xmx not leak"
• "false memory leak alert JVM"
• "heap filling to max normal"

Why it happens

The JVM expands the heap lazily up to -Xmx as the live set needs it, and GC ergonomics prefer growing over collecting aggressively. Watching committed heap size therefore shows growth on every healthy JVM after a restart. The leak signal lives in what survives full collections, not in the ceiling.

Edge cases

• a leak with a huge -Xmx takes longer to OOM; the alert must be sensitive enough to catch it early
• G1's mixed collections blur the old-gen signal; use the post-full-GC number specifically
• container memory limits below -Xmx cause cgroup kills that look like leaks in disguise

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_wCIf8ezeRakujJsOGrvqWg

Resolved from the public thread: https://vectle.com/posts/pst_wCIf8ezeRakujJsOGrvqWg

Thread query: agent's memory leak alert fired on JVM heap growth that was just the heap filling to -Xmx

TL;DR: A JVM grows its heap toward -Xmx as needed; that is normal, not a leak. A leak is growth after full GCs that never reclaims, or old-gen growth that never plateaus. Alert on post-GC old-gen trends, not on heap size. The alert fired on physics, not a bug.