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

[PROF-8074] Restore support for Ruby 3.3 #3167

Merged
merged 7 commits into from
Sep 29, 2023

Conversation

ivoanjo
Copy link
Member

@ivoanjo ivoanjo commented Sep 28, 2023

What does this PR do?

Back in #3053, a customer reported that profiling was not working on ruby-head (for Ruby 3.3).

At the time, I tracked it down to two issues:

  1. A bunch of headers had changed, and thus we needed a new release of debase-ruby_core_source to include them
  2. We were getting errors when loading the profiler due to the ruby_current_ec VM symbol no longer being available.

At the time, I chose to disable profiling on Ruby 3.3 (#3054) until we could tackle these two items.

Item 1. was fixed in #3163, that pulls in a new release of debase-ruby_core_source that includes the 3.3-preview2 headers.

This PR fixes item 2. and re-enables profiling on Ruby 3.3 (and thus reverts #3054).

Motivation:

Make sure we're in good shape for the Ruby 3.3 final release in December.

Additional Notes:

We didn't use the magic ruby_current_ec VM symbol directly. Instead, we were using GET_RACTOR() and GET_EC() which call a few methods that are defined as inline in vm_core.h.

Those methods all relied on ruby_current_ec, and thus hiding that symbol made them break.

As an alternative, we can get to the same objects by starting with the current thread, and navigating the object graph a bit.

The rb_thread_current() also relies on ruby_current_ec but crucially is not inline and is actually a public API of the VM, so that one kept working.

I hesitated on if we should use rb_thread_current() on all Rubies with Ractors, or if we should keep the fast path for 3.0 to 3.2. I ended up deciding to keep the fast path since it was quite easy to do, but in the future we could instead choose to simplify this whole thing.

P.s.: This is one of those PRs where a lot of work went into a handful of unimpressive lines of code 😅 .

This PR is on top of #3163 because it requires the new version of debase-ruby_core_source but is otherwise independent from it

How to test the change?

Validate that CI is passing on Ruby 3.3!

For Datadog employees:

  • If this PR touches code that signs or publishes builds or packages, or handles
    credentials of any kind, I've requested a review from @DataDog/security-design-and-guidance.
  • This PR doesn't touch any of that.

Fixes #3053

**What does this PR do?**

Back in #3053, a customer reported that profiling was not working
on ruby-head (for Ruby 3.3).

At the time, I tracked it down to two issues:
1. A bunch of headers had changed, and thus we needed a new
   release of `debase-ruby_core_source` to include them
2. We were getting errors when loading the profiler due to the
   `ruby_current_ec` VM symbol no longer being available.

At the time, I chose to disable profiling on Ruby 3.3 (#3054) until
we could tackle these two items.

Item 1. was fixed in #3163, that pulls in a new release of
`debase-ruby_core_source` that includes the 3.3-preview2 headers.

This PR fixes item 2. and re-enables profiling on Ruby 3.3
(and thus reverts #3054).

**Motivation:**

Make sure we're in good shape for the Ruby 3.3 final release in
December.

**Additional Notes:**

We didn't use the magic `ruby_current_ec` VM symbol directly.
Instead, we were using `GET_RACTOR()` and `GET_EC()` which call
a few methods that are defined as `inline` in `vm_core.h`.

Those methods all relied on `ruby_current_ec`, and thus hiding
that symbol made them break.

As an alternative, we can get to the same objects by starting
with the current thread, and navigating the object graph a bit.

The `rb_thread_current()` also relies on `ruby_current_ec` but
crucially **is not inline** and is actually a public API of the VM,
so that one kept working.

I hesitated on if we should use `rb_thread_current()` on all
Rubies with Ractors, or if we should keep the fast path for
3.0 to 3.2. I ended up deciding to keep the fast path since
it was quite easy to do, but in the future we could instead
choose to simplify this whole thing.

P.s.: This is one of those PRs where a lot of work went into
a handful of unimpressive lines of code 😅 .

**How to test the change?**

Validate that CI is passing on Ruby 3.3!

Fixes #3053
@ivoanjo ivoanjo requested review from a team as code owners September 28, 2023 09:52
@github-actions github-actions bot added the profiling Involves Datadog profiling label Sep 28, 2023
Base automatically changed from ivoanjo/bump-debase-ruby-core-source-3_2_2 to master September 28, 2023 10:00
@ivoanjo ivoanjo merged commit b5e3924 into master Sep 29, 2023
215 of 216 checks passed
@ivoanjo ivoanjo deleted the ivoanjo/prof-8074-restore-ruby-3_3-support branch September 29, 2023 12:58
@github-actions github-actions bot added this to the 1.15.0 milestone Sep 29, 2023
gdubicki added a commit to gdubicki/dd-trace-rb that referenced this pull request Jan 8, 2024
as it has been added in
DataDog#3167
ivoanjo pushed a commit that referenced this pull request Jan 9, 2024
as it has been added in
#3167
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
profiling Involves Datadog profiling
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Profiler incompatible with Ruby 3.3-head
2 participants