Leaks and Fragmentation

A container ceiling counts every byte the whole process holds; the configured maximum heap bounds only one region inside it. Thread stacks, runtime metadata, allocator caches and buffers living outside the managed heap are charged against the ceiling too.

The post-collection floor is the live set: the bytes still reachable once the collector has finished. Peaks only record how much garbage piled up since the previous collection, so only a rising floor shows that memory is being retained.

That is churn, not a leak. The flat 1.2 GB floor says the live set is constant; the 1.8 GB reclaimed every forty seconds says the service allocates roughly 45 MB a second of short-lived objects. The fix is allocation rate, not a retainer hunt.

Shallow size is the bytes of the object itself: header, fields and its reference slots, but not their targets. Retained size adds everything that would become unreachable if that object did, so it measures what the object keeps alive.

The hub outlives the component and still holds its handler. The handler captures the component, so a live path runs hub to handler to component, and reclamation keeps the whole object graph hanging off it.

An allocation needs one run of consecutive addresses, so it fails when no single free block is that large. The total-free figure is a sum over scattered holes and never promises a 64 MB run.

An object x dominates y when every path from a root to y passes through x. Cutting the reference that makes x reachable therefore makes the whole subtree x dominates unreachable at once, which is what its retained size counts.

The heap maximum is enforced inside the process by the runtime, which can collect, refuse an allocation and report the failure. A hard ceiling is enforced outside the process by the party that granted the memory, and nothing inside gets a turn to react.

Treat the heap maximum as a remainder, not a choice. Measure every non-heap line at peak concurrency — stacks, runtime metadata, buffers outside the managed heap, allocator overhead — add an explicit margin, subtract the total from the ceiling, then check the remainder against the live set.

Long enough that every legitimate slow fill has plateaued — bounded caches, pools, lazily built structures — and then across several complete traffic cycles, comparing floors at the same phase of each cycle. Retention does not plateau; warm-up does.

Compare aggregates, not individual objects: per-type instance counts and shallow bytes, then retained size along the same root paths. The growing type plus a holder count that stayed flat points at one container accumulating entries.

Growth that tracks cumulative distinct items, not concurrency, points at a keyed container with no eviction - a cache or registry keyed by user, tenant or query. Confirm it by correlating the footprint with that container's entry count.

Per-thread storage is scoped to the thread, not to the task. A pooled thread never ends, so a value set during one request stays attached to it - and reachable - until something explicitly removes it or a later task overwrites it.

Footprint is a high-water mark. Freed objects return their bytes to the process's own free pool, not to the operating system, and a unit of memory can only go back if nothing live remains inside it.

Pick the lever from the shape of the budget, not from habit. Only shrinking the live set or the per-request working memory reduces real demand; raising the ceiling and re-splitting the work relocate it, and re-splitting multiplies fixed per-process costs.

Use two signals with different urgencies: the post-collection floor's slope opens a ticket days ahead because it detects retention early, and proximity to the limit pages, because it means failure is imminent. Peak footprint alone pages on healthy churn and should not.

Keep something cheap always on and make the expensive capture deliberate: low-rate allocation sampling fleet-wide, snapshots taken from a drained instance, one at a time, rate-limited on the fatal path, and the files treated as a data export.

Price the failure first, then remove the cause if you can: a request that need not be one run stops failing. Everything else — early reservation, recycling, continuous consolidation — treats a symptom at a different price.

A maximum heap is permission to grow, not a reservation of what the program needs. Raise it and the runtime reclaims later, keeps unreclaimed objects resident longer, and lets the process footprint drift up toward a ceiling the heap setting does not know about.

Because not every floor is the same measurement. A floor taken after a collection that visited only part of memory still contains garbage the collection never looked at, so a series of such floors can drift while the reachable set is flat. Compare floors of equal scope.

Sampling one allocation per fixed interval of bytes estimates bytes per site well, but hides any site whose total allocation is far below one interval and makes object counts noisy. Both forms profile birth, not survival.

A handle is a small managed object attached to a large resource the collector does not measure - kernel structures and off-heap buffers. Heap pressure therefore never rises, no collection is provoked, and the real memory is released only by an explicit close.

Relocation needs permission. An object whose address has escaped the manager, or that is too costly to copy, is pinned in place, and one immovable object stops its whole unit being emptied and merged.