Issue #2565 has been updated by Aaron Patterson.

Assignee changed from Yuki Sonoda to Aaron Patterson

Since I really want this feature, I should update this ticket with my progress.

I've ported the Joyant probes to trunk (and added a few).  You can view the progress I've made here:

  https://github.com/tenderlove/ruby/tree/probes

I use this branch on a daily basis with no noticeable performance penalties, but I have a few tasks remaining before I want to call my work "done".

1. Probe stability declarations

One concern that ko1 had was people relying on DTrace probe APIs.  DTrace allows us to declare the stability of any particular probe.  This allows us to tell DTrace consumers how much they should rely on that particular API.  I like the API of the probes I've added (and the Joyant probes), so I don't want to change them.  However, it may be useful to declare them as unstable until we've had multiple ruby releases that contain the probes (and the community is happy with the API).

2. Tests

I've started writing tests for the probes, but there is a challenge.  DTrace can only be enabled by a user with elevated permissions, so the tests must be run with sudo.  It's easy enough to write tests that will only execute when the user has the correct permissions, but I'm not sure what we should do about CI.

3. Autotools generating probes.h

I don't understand autotools very well, so I need help with this task.  At rubyconf, nobu helped me patch Makefile.in to generate the probes.h file, but it doesn't seem to automatically generate on my system.  I'm not entirely sure what the problem is.

  https://github.com/tenderlove/ruby/commit/3f645ce71e29859256063265cfd03ffd52d38dd8

When I run `rm probes.h; make`, the probes.h file is not regenerated.  I don't understand what is wrong.  Any help would be greatly appreciated.

That's all the updates I have for now!
----------------------------------------
Feature #2565: adding hooks for better tracing
https://bugs.ruby-lang.org/issues/2565

Author: Yuki Sonoda
Status: Assigned
Priority: Low
Assignee: Aaron Patterson
Category: core
Target version: 2.0.0


=begin
 Hi,
 
 I made a commit that embeded dtrace probes into Ruby so that you can
 profile a Ruby application at runtime. (r26235)
 
 Adding probes had been approved by a Ruby developer's meeting,
 however, the commit was little larger than what other committers
 expected. I got some objection for the commit. [ruby-dev:39954]
 In the end, I decided to temporarily revert the commit. (r26243)
 
 I discussed how we should support dynamic runtime tracing, with ko1,
 mame, naruse, unak and shyouhei. The problems of the commit were:
 * the probes duplicated with the event_hook framework
 (rb_add_event_hook, Kernel#set_trace_func)
 * Design of the probes were not verified enough.
   * more trial and error are necessary, to make it clear what is
 necessary to trace a Ruby application.
 
 I accepted ko1's suggestion:
 * reverting the commit
 * adding some hooks for rb_add_event_hook().
 * implementing probes for dynamic runtime tracing on the event_hook framework.
   * these probes can be implemented as a gem
   * I will aget a chance for trial and error.
   * The probes possibly will be merged into Ruby itself after enough
 designed and getting enough use cases.
 
 Here is a patch to add the hooks I and ko1 talked about. (attached)
 And here is an extension library that provides prove points to dtrace,
 on top of the hooks. (http://github.com/yugui/vm_probes )
 
 What do you think?  Can I commit the patch I attached?
 
 Thank you,
 -- Yuki Sonoda (Yugui)
 
 Attachment: adding-hooks.patch
=end



-- 
http://bugs.ruby-lang.org/