Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Output aggregated allocation call stacks #303

Open
Lukasa opened this issue Jan 17, 2025 · 3 comments
Open

Output aggregated allocation call stacks #303

Lukasa opened this issue Jan 17, 2025 · 3 comments

Comments

@Lukasa
Copy link

Lukasa commented Jan 17, 2025

package-benchmark makes it very easy to guard against regressions in allocation counts. However, when a regression does occur, it does not offer much in the way of diagnostic tools to work out where the new allocation was added. In principle Instruments or dtrace can be used to determine this, but the output from those tools is tainted somewhat by the package-benchmark harness itself, as those tools don't know what the measurement window was.

A very useful feature would be a flag to record and output aggregated allocation call stacks. If those stacks are also sorted by allocation count (or output in a structured format that is amenable to further automated processing) it will make it a lot easier to quickly compare the allocations from the before/after flow and determine where the new allocations are.

There are some risks here. Care will need to be taken not to heap allocate in the process of walking the call stack, or we'll trigger infinite recursion. We'll also need to consider how much effort we want to put into supporting older Swift releases, or cases where the frame pointer has been omitted. If we choose not to care about the cases where the frame pointer is omitted, walking the stack should be fairly easy.

@hassila
Copy link
Contributor

hassila commented Jan 31, 2025

Hi @Lukasa , that would be useful, agree - in general I want to avoid going too much into the deeper analytics territory of dtrace/instruments, but this specific issue would be super useful to make easy.

Perhaps the jemalloc sampling could be leveraged here (https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Heap-Profiling) - although this is only sampling (but perhaps it will be useful enough in practice if the output can be compared easily? Need to check into the output. WDYT?

@FranzBusch
Copy link

I tried using jemalloc for this already but it sadly doesn't allow to capture a stack trace on each allocation. It rather shows you the heap usage. What we really need is to hook the swift_alloc calls to then capture a back trace on each allocation.

@hassila
Copy link
Contributor

hassila commented Jan 31, 2025

@FranzBusch I had some good results with heap track earlier, it is slightly documented here
https://www.swift.org/documentation/server/guides/memory-leaks-and-usage.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants