Skip to content

[PROF-13510] Add Ruby 4 heap profiling test variants#89

Merged
ivoanjo merged 5 commits intomainfrom
ivoanjo/prof-13510-ruby4-heap-profiling
Feb 10, 2026
Merged

[PROF-13510] Add Ruby 4 heap profiling test variants#89
ivoanjo merged 5 commits intomainfrom
ivoanjo/prof-13510-ruby4-heap-profiling

Conversation

@ivoanjo
Copy link
Member

@ivoanjo ivoanjo commented Jan 29, 2026

What does this PR do?

This PR adds Ruby 4 heap profiling test variants. As per DataDog/dd-trace-rb#5201, we need a different implementation of heap profiling on Ruby 4, so we want to validate it's still sane with prof-correctness.

These variants are effectively the same as the regular ones but:

  • Replace Ruby 3.3 with Ruby 4.0
  • Point to the branch from [PROF-13510] Heap profiling for ruby 4.x dd-trace-rb#5201 (we'll need to change this back to master once landed) No longer needed
  • Set the DD_PROFILING_EXPERIMENTAL_HEAP_RUBY4_ENABLED env variable we're using to gate the new feature No longer needed
  • Update the expected_profile.json to take into account that object allocation in Ruby 4 produces a slightly different stack trace (there's no new method on the stack -- it gets inlined into the caller)

Motivation:

Validate Ruby 4 heap profiling.

Additional Notes:

There's still a few anomalies in the results we're looking into...

How to test the change?

Run as usual!

**What does this PR do?**

This PR adds Ruby 4 heap profiling test variants. As per
DataDog/dd-trace-rb#5201, we need a different
implementation of heap profiling on Ruby 4, so we want to validate
it's still sane with prof-correctness.

These variants are effectively the same as the regular ones but:
* Replace Ruby 3.3 with Ruby 4.0
* Point to the branch from
  DataDog/dd-trace-rb#5201 (we'll need to
  change this back to master once landed)
* Set the `DD_PROFILING_EXPERIMENTAL_HEAP_RUBY4_ENABLED` env
  variable we're using to gate the new feature
* Update the `expected_profile.json` to take into account that
  object allocation in Ruby 4 produces a slightly different stack
  trace (there's no `new` method on the stack -- it gets inlined
  into the caller)

**Motivation:**

Validate Ruby 4 heap profiling.

**Additional Notes:**

There's still a few anomalies in the results we're looking into...

**How to test the change?**

Run as usual!
We're using `go test` here [which defaults to 10
minutes](https://pkg.go.dev/cmd/go#hdr-Testing_flags). Our Ruby tests
are running for 50 seconds each by default, so the addition of extra
tests pushed us over the limit.

I've raised the limit to 20 minutes which should be enough. We could
disable it in the future, but I do like the reminder that we are taking
too long and might need to do something else instead ;)
@ivoanjo ivoanjo force-pushed the ivoanjo/prof-13510-ruby4-heap-profiling branch from 20287c7 to ee345fb Compare February 10, 2026 09:07
@ivoanjo ivoanjo marked this pull request as ready for review February 10, 2026 09:19
@ivoanjo ivoanjo requested a review from a team as a code owner February 10, 2026 09:19
]
},
{
"regular_expression": "^<main>;each;<main>;times;<main>;b;new$",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💭 I can't remember what is the logic on having new or not in the stack

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's an actual upstream behavior change -- we fixed up our tests in DataDog/dd-trace-rb#4656 and the upstream change (with a really nice explanation) is ruby/ruby#13080 .

Copy link
Collaborator

@r1viollet r1viollet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! LGTM

@ivoanjo
Copy link
Member Author

ivoanjo commented Feb 10, 2026

Going ahead and merging this one! Two final notes:

  1. I've dropped a "see something, say something" note about the node/python CI failures but they are completely independent from the Ruby changes

  2. While working on this branch I sometimes saw ruby_heap_bias_r4 fail on my local machine due to results being a bit over the error margins than expected.

    This is what I was alluding to in the PR notes when I said "There's still a few anomalies in the results we're looking into...". I've since not been able to reproduce the issue -- even using the exact same commit hashes and whatnot. I still want to run a few more experiments, but I don't think that should block us from merging this in -- in fact, if this re-occurs in CI it may help provide extra info for the investigation; or maybe it never re-occurs and I'll forever be wondering what happened on those runs.

@ivoanjo ivoanjo merged commit d1de9ef into main Feb 10, 2026
7 of 9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

Comments