[PROF-9476] Reduce heap profiling overhead by using libdatadog's managed string storage

[ivoanjo]

What does this PR do?

This PR changes the heap profiler to use the new libdatadog managed string storage API added in DataDog/libdatadog#725 . (And thanks to Alex for starting this work in #3628 )

Prior to this PR, the heap profiler was doing all of the work of keeping stack traces around for the objects being tracked. This involved keeping copies of all strings for path / function names, and also having a clever deduplication mechanism that allowed us to dedup stack traces without first copying all of the strings.

The libdatadog managed string storage allows us to simplify this work by giving us a string table we can use to store strings and trade them for long-lived ids. Then these ids can be used then adding samples to libdatadog, instead of direct pointers to the strings.

This has a bunch of advantages:

1. We were not previously deduplicating strings in the heap profiler, only whole stacks.

   Thus if we had /path/a.rb:method_a -> /path/b.rb:method_b -> /path/c.rb:method_c multiple times, we would deduplicate them. But if we also had /path/a.rb:method_a -> /path/b.rb:method_b, then we'd store yet another copy of these strings. This is no longer the case when using the new API.

2. Representing stacks as arrays of ids means deduplication, hashing and comparison is much faster -- we're only comparing ids and not the contents of strings.

3. When feeding stacks again to libdatadog, it's cheaper to use ids since libdatadog doesn't need to keep re-hashing the strings to de-duplicate them; it can use the ids to do that.

This does mean that this PR is a bit... on the noisy side in terms of changes to the heap profiler. Specifically, it takes advantage of most of the simplification opportunities that managed string stable allows:

• It merges heap_record and heap_stack structures as they no longer need to exist independently, and then rips out as much code as possible based on that merge
• It simplifies stack comparison and hashing

Update: As discussed, I've pushed a commit to set experimental_heap_sample_rate to 1, raising the heap sampling rate from its previous default of 10.

Motivation:

The key objective of this work is allowing us to reduce the memory and cpu overhead of heap profiling.

Earlier versions of this PR already showed reduced memory usage. I decided to open this PR already and do benchmarking in parallel, so I don't yet have updated numbers yet.

See below.

Change log entry

Yes. Reduce overhead of heap profiling

Additional Notes:

Currently CI is broken for this PR because it depends on DataDog/libdatadog#844 which has not yet been merged into libdatadog.

Obviously I plan to make sure that PR is in libdatadog, and that master is using the latest libdatadog before merging this PR, but I don't think it makes sense to hold off on review until that's the case.

How to test the change?

The existing test coverage was already quite reasonable. I added a few more tests to make sure that our stack recording/retrieval/deduping was in good shape, as well as a benchmark for the efficiency of the interning operations.

---

Benchmarks:

I wrote up my results in this doc (Datadog-internal). Here's a quick recap of what I saw.

High load gitlab:

Here, we’re comparing 4 configurations:

• baseline: Unmodified application, no profiling at all
• only-profiling-heap: Application running cpu + wall-time + allocation + heap profiling, without managed string storage; using heap sampling defaults
• only-profiling-heap-mss: Same as above, but using managed string storage branch
• only-profiling-heap-mss-sr1: Same as above, but with heap profiling sampling 1:1 with allocation profiler

Configuration	Min memory RSS (MiB)	Max memory RSS (MiB)	Avg memory RSS (MiB)	AVG virtual memory (GiB)
baseline worker 0	893	908	900	1.4
baseline worker 1	894	911	902	1.4
only-profiling-heap worker 0	959	985	972	1.7
only-profiling-heap worker 1	959	980	970	1.7
only-profiling-heap-mss worker 0	937	964	955	1.6
only-profiling-heap-mss worker 1	934	962	951	1.6
only-profiling-heap-mss-sr1 worker 0	956	980	968	1.6
only-profiling-heap-mss-sr1 worker 1	946	979	965	1.6

Rails app:

Here, we’re comparing 5 configurations:

• baseline: Unmodified application, no profiling at all
• candidate-heap-profiling: Application running cpu + wall-time + allocation + heap profiling, without managed string storage; using heap sampling defaults
• candidate-heap-profiler-mss: Same as above, but using managed string storage branch
• candidate-heap-profiler-mss-sr1: Same as above, but with heap profiling sampling 1:1 with allocation profiler
• candidate-heap-profiling-sr1: Additional data point: what if we enabled 1:1 sampling the allocation profiler without the managed string storage?

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.77%. Comparing base (6021b3d) to head (de97855).
Report is 89 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4331      +/-   ##
==========================================
+ Coverage   97.75%   97.77%   +0.01%     
==========================================
  Files        1351     1362      +11     
  Lines       82684    84824    +2140     
  Branches     4197     4411     +214     
==========================================
+ Hits        80827    82933    +2106     
- Misses       1857     1891      +34     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ivoanjo]

Don't forget to update the changelog once benchmarking results are ready. (e.g. claim both memory and cpu improvements)

👍 Updated PR description with results!

[pr-commenter]

Benchmarks

Benchmark execution time: 2025-02-18 11:32:43

Comparing candidate commit de97855 in PR branch ivoanjo/prof-9476-managed-string-storage-try2 with baseline commit 6021b3d in branch master.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 33 metrics, 2 unstable metrics.

[ivoanjo]

Update: As discussed, I've pushed a commit to set experimental_heap_sample_rate to 1, raising the heap sampling rate from its previous default of 10.