Feature #10602: Support multithreaded profiling

• Status: Closed
• Assignee: -
• Target version: -

[mperham (Mike Perham)]

The current rb_profile_frames captures the frame for whatever thread is current. This makes profiling a multithreaded system impossible. I'd like a rb_thread_profile_frames which captures a given thread. It seems like it would be a very simple change, something like this:

int
rb_profile_frames(int start, int limit, VALUE *buff, int *lines)
{
    rb_profile_frames(start, limit, buff, lines, GET_THREAD())
}

int
rb_thread_profile_frames(int start, int limit, VALUE *buff, int *lines, rb_thread_t *th)
{
    int i;
    rb_control_frame_t *cfp = th->cfp, *end_cfp = RUBY_VM_END_CONTROL_FRAME(th);
    ...

This way profiling gems could lock to a specific thread.

[mperham (Mike Perham)]

To be clear, I want to profile a single thread within a running multithreaded Ruby app. This is useful for profiling individual Sidekiq jobs executing in production. Right now the profile frames capture data from other threads which makes the output useless.

[jeremyevans0 (Jeremy Evans)]

• Tracker changed from Bug to Feature
• ruby -v deleted (2.1.5)
• Backport deleted (2.0.0: UNKNOWN, 2.1: UNKNOWN)

[ivoanjo (Ivo Anjo)]

PR to implement this being discussed in https://github.com/ruby/ruby/pull/7784

• Status changed from Open to Closed

Applied in changeset git|4adf418be963b3554962b2f27057be81486c57d9.

---

[Feature #10602] Add new API rb_profile_thread_frames()

Add a new API rb_profile_thread_frames(), which is essentialy a
per-thread version of rb_profile_frames().

While the original rb_profile_frames() always returns results about the
current active thread obtained by GET_EC(), this new API takes a Thread
to be profiled as an argument.

This should come in handy when profiling I/O-bound programs such as
webapps, since this new API allows us to learn about Threads performing
I/O (which do not have the GVL).

Profiling worker threads (such as Sidekiq workers) may be another
application.

Implements [Feature #10602]

Co-authored-by: Mike Perham [e-mail]