From: Rocky Bernstein Date: 2010-01-06T23:49:06+09:00 Subject: [ruby-core:27449] Re: [Feature:trunk] adding hooks for better tracing --001636e1f73d528d48047c800e0d Content-Type: text/plain; charset=ISO-8859-1 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 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) > --001636e1f73d528d48047c800e0d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is somewhat related to work I've been doing on and off (but recent= ly mostly off) with regard to writing a debugger for Ruby 1.9. See
http://github.com/rocky/rbdbgr a= nd http://github.com/roc= ky/rb-threadframe.

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

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

I am optimistic in the future that "position" may expand to s= ay a line and column number offset. Perhaps some would prefer a byte or uni= code offset. Or perhaps a range columns (and lines). And for a position tha= t 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 st= ructure. In other programming systems there is sometimes a packaging contai= ner which is like a tarball. Here "file" may need to refer not on= ly to the tarball location but also a member inside that packaging containe= r.



On Wed, Jan 6, 2010 at 9:15 AM, Yugu= i <yugui@yugui.jp> 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.
=A0* 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 framewo= rk.
=A0* these probes can be implemented as a gem
=A0* I will aget a chance for trial and error.
=A0* 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? =A0Can I commit the patch I attached?

Thank you,
-- Yuki Sonoda (Yugui)

--001636e1f73d528d48047c800e0d--