Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

AndyArmstrong (7200)

AndyArmstrong
  (email not shown publicly)
http://hexten.net/
Sunday January 06, 2008
11:42 AM

Devel::DTrace

[ #35306 ]

Since installing Mac OS 10.5 I've been falling in love with dtrace. I'd like to have dtrace instrumentation built into Perl as standard. Last night I started playing around with Alan Burlison's experimental dtrace patch and in particular with Richard Dawe's modified version of Alan's patch.

I made some progress and got the patch to apply cleanly against bleadperl and made a couple of changes (simplifications actually) to correspond with how dtrace itself has evolved.

This morning it occurred to me that I might be able to add the dtrace probes to a replacement runops loop instead of making it a compile time option for Perl itself. As a result I've just released Devel::DTrace.

Having launched a Perl process like this

perl -MDevel::DTrace someprog.pl

you can attach to it with dtrace and watch the subroutine calls go by.

For the next release of Devel::DTrace I plan to have it build a custom probe-enabled interpreter, dtperl (which is quite simple) which will be nearly as good as having probes hard wired into Perl.

I'd still like to get dtrace into core but doing so depends on minimising the performance hit that's incurred. At the moment the probe code works out the subroutine name, file and line number for every entry and exit even if the probe is disabled. The recommended solution (as per Alan's article linked above) is to move that decode logic out of Perl and into dtrace - but that's not trivial because the code has to do different things depending on how Perl is built.

In the mean time if you have a system that supports dtrace please give Devel::DTrace a try.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • the tests fail on my install of solaris because -h isnt a valid option for dtrace. in a spooky coincidence my cpan testing had just got to it when i was reading the post.
    • Ah, thanks. More seriously it's getting a bus error on non-trivial programs. Needs work I think :)
      • Its failing on Leopard too, but I am getting: cc -c -Wall -O3 -DVERSION=\"0.03\" -DXS_VERSION=\"0.03\" "-I/System/Library/Perl/5.8.8/darwin-thread-multi-2level/CORE" runops.c runops.c: In function '_curcv': runops.c:10: error: 'dVAR' undeclared (first use in this function) runops.c:10: error: (Each undeclared identifier is reported only once runops.c:10: error: for each function it appears in.) make: *** [runops.o] Error 1 ANDYA/Devel-DTrace-0.03.tar.gz /usr/bin/make -- NOT OK Running make test C
        • Ah - that must be because I'm using Perl 5.10. Silly me. Thanks for the report. I'll fix that and get another release out.
          • Cool, I look forward to it. I'll test! ;)
            • I think 0.04 should be working on vanilla Mac OS Perl now. It certainly works for me.

              I really need to think about how to test it. It's a bit awkward given that dtrace needs to run as root.

              I guess I can at least test the logic by building a version containing different probes that just output to STDERR.

              Sorry folks, I'm talking to myself now :)

  • I've just released 0.03 which creates and installs a Perl interpreter called dtperl which contains dtrace probe hooks.

    In the process I fixed a nasty little bus-error-causing problem.

    Now I need to install Solaris and get it working there.

  • see http://distributedinformation.com/ [distribute...mation.com]

    I've been working my way through the perl 5.8.8 source - talk about an education. Right now, I'm adding probes to a few of the run ops - adding parameter outputs as I work out what to do. My focus is a little different - I want a way to instrument in production cgi code - though I notice there would be a use for this to determine that really should be in hot_ops.

    I've been working on 5.8.8 in a publicly accessible svn repository - in case anyone wants to try it.

    Sven