perf(memtrack): stop capturing stacks on free

[not-matthias]

Why

Memory flamegraphs only attribute allocations. The platform's memtrack-parser unwinds stacks attached to Free events and caches the callchain, but only allocation samples are folded, so free stacks are never read.

With stack capture on by default, every free() still paid the full capture: an 8 KiB user-stack copy, the FNV hash, bpf_get_stackid, and (since exact-hash dedup is ~0% effective) a full record into the stack ring. That is roughly half of all captures.

What

• free uprobe no longer calls capture_stack; submit_free_event drops the hash.
• MemtrackEventKind::Free is a unit variant. The serialized form is unchanged (stack_hash was already skipped when zero), and artifacts written by older memtrack versions with a stack_hash on frees still decode (covered by legacy_free_with_stack_hash_decodes).
• Stack test snapshots print Free without the has_stack flag.

Expected effect

About half the stack captures, stack ring writes, encode CPU, and archive stack bytes on allocation-heavy benchmarks; less unwinding work in callgraph generation. To be measured on the platform memory shards (COD-3703).

[greptile-apps]

Confidence Score: 4/5

[Medium risk] Memory tracking stops capturing stack traces on free operations.

The PR is not ready to merge because a near-limit Memory or WallTime profile can fail upload without a compression attempt.

Summary

The PR removes stack capture from free events and makes Free a unit variant. Changes since the previous review also export a run ID as a GitHub Actions step output and enforce a 5 GiB profile-archive limit.

• The archive limit has a boundary case that can reject a compressible profile without attempting compression.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A[Memory or WallTime profile folder] --> B{Folder at least 5 GiB?}
  B -- Yes --> C[Create gzip tar]
  B -- No --> D[Create uncompressed tar]
  C --> E{Archive over 5 GiB?}
  D --> E
  E -- Yes --> F[Abort upload]
  E -- No --> G[Upload archive]

Loading

_{Reviews (4) · Last reviewed commit: "refactor(memtrack): drop stack_hash from..."}

[codspeed]

Merging this PR will improve performance by 19.2%

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

⚡ 1 improved benchmark
✅ 32 untouched benchmarks
⏩ 4 skipped benchmarks¹

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
⚡	WallTime	memtrack track tar	9.4 s	7.9 s	+19.2%

Tip

Curious why performance improved? Comment @codspeedbot explain why performance improved on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing cod-3703-eval-performance-overhead-of-memory-flamegraphs (c01f5d2) with main (fabf8e4)}

Footnotes

1. 4 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[GuillaumeLagrange]

olgtm