[ruby-core:27449] Re: [Feature:trunk] adding hooks for better tracing

This is somewhat related to work I've been doing on and off (but recently
mostly off) with regard to writing a debugger for Ruby 1.9. See
http://github.com/rocky/rbdbgr and http://github.com/rocky/rb-threadframe.

In doing that, one thing I observe is that a lot of the event hook
parameters are not needed if one has the notion of a stack frame and/or a
binding. (Sure, for backward compatibility and to perhaps to keep Ryan Davis
happy, one might consider this an additional or alternative hook.)

The second thing I would suggest is that right now although there is the
fixation with "file" and "line", I think what one wants is the nothing of a
"container" and "position" inside the container. Many times these are the
same thing as "file" and "line", but don't necessarily have to be so.

I am optimistic in the future that "position" may expand to say a line and
column number offset. Perhaps some would prefer a byte or unicode offset. Or
perhaps a range columns (and lines). And for a position that started out as
parse tree structure, perhaps it is something else.

As for "file" versus "container", remember that one can dynamically compile
a file from a Ruby string or some other sort of structure. In other
programming systems there is sometimes a packaging container which is like a
tarball. Here "file" may need to refer not only to the tarball location but
also a member inside that packaging container.



On Wed, Jan 6, 2010 at 9:15 AM, Yugui <[e-mail]> wrote:

> 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)
>