Skip to content

Make tracepoints with set_trace_func or TracePoint.new ractor local#7184

Open
luke-gru wants to merge 1 commit intoruby:masterfrom
luke-gru:tracepoint_ractor_gc
Open

Make tracepoints with set_trace_func or TracePoint.new ractor local#7184
luke-gru wants to merge 1 commit intoruby:masterfrom
luke-gru:tracepoint_ractor_gc

Conversation

@luke-gru
Copy link
Copy Markdown
Contributor

Before this change, GC'ing any Ractor object caused you to lose all enabled tracepoints across all ractors (even main). Now tracepoints are ractor-local and this doesn't happen.

Fixes [Bug #19112]

NOTE: I have yet to change the docs for TracePoint to mention that they are ractor-local, but I'm going to do that
in a separate PR. Also, I want to make it so that there's a flag to TracePoint#enable to make them global.

@luke-gru
Copy link
Copy Markdown
Contributor Author

This broke some internal events tests, like GC events, so I'll take a look soon.

@ivoanjo
Copy link
Copy Markdown
Contributor

ivoanjo commented Jan 26, 2023

Thanks for picking up this fix!

Also, I want to make it so that there's a flag to TracePoint#enable to make them global.

This would be great as well! I work on the profiler included in the ddtrace gem and while we don't have support for gathering information from non-main Ractors yet, it would be great if there was a global mechanism to say "I want to get informed of things, regardless of where they come from".

This way, we won't have to do things like intercept Ractor creation to make sure we reactivate our tracepoints for every new one that gets created.

Even if such an API is only available from C (I understand it may be harder to get Ruby-level tracepoints working cross-ractor), it would be incredibly valuable :)

@luke-gru luke-gru force-pushed the tracepoint_ractor_gc branch from ff26fcd to 06ead01 Compare January 26, 2023 13:49
@luke-gru
Copy link
Copy Markdown
Contributor Author

luke-gru commented Jan 26, 2023

Thanks for picking up this fix!

Not a problem 😄

I think a :global keyword being introduced for TracePoint#enable would be good. It doesn't look too complicated to get global tracepoint hooks to work alongside ractor hooks, but I'll leave that work for a separate commit and after (or if) this gets accepted.

@marknuzz
Copy link
Copy Markdown

Just wanted to follow up to ask if there's any plans to finish this. This would help enable reliable memory allocation profiling in our infrastructure.

@luke-gru
Copy link
Copy Markdown
Contributor Author

luke-gru commented Apr 7, 2025

This should be getting more attention soon. I plan on working on the 'debug' gem to enable breakpoints to work inside Ractors, and this PR would enable that work.

Before this change, GC'ing any Ractor object caused you to lose all
enabled tracepoints across all ractors (even main). Now tracepoints are
ractor-local and this doesn't happen. Internal events are still global.

Fixes [Bug #19112]
@luke-gru luke-gru force-pushed the tracepoint_ractor_gc branch from c797f88 to 35cceee Compare December 5, 2025 17:48
@luke-gruber
Copy link
Copy Markdown
Contributor

@ivoanjo @marknuzz Ractor-local tracepoints was merged into ruby 4.0.0 with PR #15468. Please experiment with it and let me know how it works for you 😄 . There is no way to create a global TracePoint that works across all ractors, but we probably will add this in the future.

@ivoanjo
Copy link
Copy Markdown
Contributor

ivoanjo commented Jan 5, 2026

Please experiment with it and let me know how it works for you 😄 .

It does! I just checked and the tracepoint we use for GC and the one we use for NEWOBJ no longer get disabled on Ruby 4.

We have some documentation in the Datadog gem about this issue, I'm about to open a PR to update it to mention that it's a Ruby 3.x issue only, and fixed on Ruby 4.

There is no way to create a global TracePoint that works across all ractors, but we probably will add this in the future.

This will indeed be quite useful :)

I mentioned above we don't have support for observing non-main ractors in the datadog gem, and that's still the case; but with the renewed push to get Ractors to be non-experimental, this is something we'll need to support in the future.

ivoanjo added a commit to DataDog/dd-trace-rb that referenced this pull request Jan 5, 2026
**What does this PR do?**

For a while now, whenever the GC and more importantly the allocation
profiling features were enabled, we logged a user-visible message that
if Ractors were used, a bug in Ruby could cause the profiler to miss
data (due to https://bugs.ruby-lang.org/issues/19112 ).

The upstream issue has been fixed in
<ruby/ruby#15468> (some discussion as well
in <ruby/ruby#7184> ).

Thus, this PR does a few small things:

* Update the logged messages to mention the bug doesn't happen on
  Ruby 4

* Moves all messages to be debug-level messages (our logic already
  made sure they were only printed on Ruby 3, hah turns out we
  predicted this!)

  In particular our concern in the past for making the message
  user-visible by default was that customers might use Ractors and
  run into this issue. As it turns out that in Ruby 3 ractors were
  always experimental and had a number of bugs/issues, we don't
  expect anyone to run Ractors in production with Ruby 3. (Maybe
  this will change with Ruby 4?)

* Removes the `OnlyOnce` that was used to limit verboseness -- this
  is extra complexity that we don't need to maintain now that the
  log is debug level

**Motivation:**

Avoid annoying customers with log messages about Ractor support on
Ruby 3.

**Additional Notes:**

N/A

**How to test the change?**

For the warnings themselves, I've updated our tests to match the
new setup.

For the upstream issue, I manually used the testcase from
https://bugs.ruby-lang.org/issues/19112 and added prints to the
profiling GC and NEWOBJ tracepoints, confirming that on Ruby 3.4
they get disabled but on Ruby 4.0 they work fine.

I considered adding an explicit test for this but it seems a bit
brittle as it would be a test for something not happening after
Ractor GC which is kinda fishy to test for, so I ended up not doing
it.
@luke-gruber
Copy link
Copy Markdown
Contributor

It does!

Awesome, thank you for checking!

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.

4 participants