Improve -e alloc --live to better highlight potential memory leaks

Describe the feature

Hi,

First of all, thanks for the great tool — async-profiler has been extremely useful for memory and CPU profiling.

I would like to suggest an enhancement for the -e alloc event when used with --live.

Current behavior

When running:

-e alloc --live

the profiler reports all currently live (not yet garbage-collected) objects. However, this includes a large number of short-lived objects that simply haven't been collected yet.

As a result, the output often represents the current heap state rather than highlighting suspicious memory retention or potential leaks.

Problem

From a memory leak analysis perspective, this behavior makes it harder to identify truly problematic allocations, because:

• Recently allocated objects (after the last GC) are included
• These objects are often not leaks, just not yet collected
• The signal-to-noise ratio is relatively low

Suggestion

It would be very helpful if async-profiler could optionally exclude objects allocated after the last GC cycle.

For example, a mode like:

-e alloc --live --exclude-after-last-gc

(or similar)

This would:

• Focus on objects that survived at least one GC cycle
• Better approximate long-lived objects
• Improve usefulness for memory leak detection

Alternative ideas

• Provide a "survived GC" filter or threshold
• Integrate with GC events to mark allocation epochs
• Offer a mode that approximates "old generation survivors"

Expected benefit

This enhancement would make alloc + live much more effective for identifying memory leaks, rather than just reflecting current heap occupancy.

Thanks for considering this suggestion!

Use Case

I'm using -e alloc --live to analyze potential memory leaks, but the result includes many recently allocated objects that haven't been garbage collected yet.

These objects are usually not leaks, which introduces significant noise and makes it harder to identify real memory retention issues.

I need a way to focus on objects that survived at least one GC cycle, rather than all currently live objects.

Proposed Solution

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change