[PROF-9470] Enable "heap clean after GC" profiler optimization by default

[ivoanjo]

What does this PR do?

This PR changes the optimization added in #4020 to be enabled by default.

I've collected a fresh set of benchmarking results for this feature in this google doc.

The TL;DR is that results seem to be... very close. E.g. sometimes we slightly improve things, but often the numbers seem too close to tell.

But on the other hand this also means that there are no regressions, and thus no reason not to enable the feature by default.

Motivation:

As a recap, without this optimization, the Ruby heap profiler works by sampling allocated objects, collecting and keeping metadata about these objects (stack trace, etc). Then, at serialization time (every 60 seconds), the profiler checks which objects are still alive; any objects still alive get included in the heap profile; any objects that have since been garbage collected get their metadata dropped.

The above scheme has a weak-point: some objects are allocated and almost immediately become garbage collected. Because the profiler only checks for object liveness at serialization time, this can mean that in the extreme, an object born and collected at the beginning of the profiling period can still be tracked for almost 60 seconds until the profiler finally figures out that the object is no longer alive.

This has two consequences:

1. The profiler uses more memory, since it’s collecting metadata for already-dead objects
2. The profiler has more work to do at the end of the 60-second period – it needs to check an entire 60 seconds of sampled objects

The heap profiling clean after GC optimization adds an extra mechanism that, based on Ruby GC activity, triggers periodic checking of young objects (e.g. objects that have been alive for few GC generations). Thus:

a. The profiler identifies and clears garbage objects faster,
thus overall needing less memory
b. The profiler has less work to do at the end of the 60-second
period
...trading it off with a smaller periodic pass

Change log entry

Enabled "heap clean after GC" profiler optimization by default

Additional Notes:

I've also removed the separate benchmarking configuration, to avoid having too many long-running benchmarking variants.

How to test the change?

I've updated the specs for the setting, and the optimization itself has existing test coverage that was added back in #4020.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.73%. Comparing base (d7cd566) to head (da099a9).
Report is 8 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #4085   +/-   ##
=======================================
  Coverage   97.72%   97.73%           
=======================================
  Files        1338     1338           
  Lines       80251    80259    +8     
  Branches     4017     4017           
=======================================
+ Hits        78428    78438   +10     
+ Misses       1823     1821    -2     

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

[Strech]

LGTM

[pr-commenter]

Benchmarks

Benchmark execution time: 2024-11-07 15:45:43

Comparing candidate commit da099a9 in PR branch ivoanjo/prof-9470-enable-heap-clean-after-gc-default with baseline commit f679de4 in branch master.

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

scenario:profiler - sample timeline=false

• 🟩 throughput [+0.589op/s; +0.601op/s] or [+9.461%; +9.658%]