dtrace discuss - Feb 2009 - stack() and ustack() as first-class objects

Are there any subtle reasons why DTrace can''t treat stack traces as
first-class objects?  They''re already slightly better than
second-class objects because we can use them as the key to
aggregations, but we can''t assign them as variables.

(Note, I haven''t looked closely at the code yet to see what would be
involved.  I''m mostly curious if this would break-or-overly-complicate
things in a manner similar to adding if-then statements.)

What''s driving this is that I want to be able to do application
profiling, but I want to be able to include a stack trace for when the
profile probe fires but the application isn''t on CPU.

For example, given a program that does nothing more than "sleep(10)",
I can currently see the output of the first command, but what I want
to see is the output of the second:

# dtrace -n ''profile-597/pid == $target/{@[ustack()] =
count()}'' -c ./a.out
dtrace: description ''profile-597'' matched 1 probe
dtrace: pid 753689 has exited


              libc.so.1`getenv
              libc.so.1`libc_init+0x5b0
              ld.so.1`rt_thr_init+0x41
              ld.so.1`setup+0x13be
              ld.so.1`_setup+0x310
              ld.so.1`_rt_boot+0x56
              0x8047e78
                1
# ./uprof.d -c ./a.out

              libc.so.1`0xfee633ca
                1

              ld.so.1`rtld_db_postinit
              ld.so.1`setup+0x1414
              ld.so.1`_setup+0x310
              ld.so.1`_rt_boot+0x56
              0x8047e7c
                2

              libc.so.1`__nanosleep+0x7
              libc.so.1`sleep+0x31
              a.out`main+0xf
              a.out`_start+0x7d
             5970
#

Where the code for uprof.d would look like this (which only works for
the single-threaded case as written):

off-cpu
/ pid == $target /
{
         mystack = ustack();

        /* curcpu could be 0, but we want to use mycpu in predicates. */
        mycpu = cpu + 1;
}

on-cpu
/ pid == $target /
{
        mystack = "";
        mycpu = 0;
}

/*
 * If we''re on-cpu, count this stack trace.
 */
profile-597
/ pid == $target /
{
        @c[ustack()] = count();
}

/*
 * If we''re not on-cpu, and this is the cpu we last ran on, count
 * our last recorded stack.
 */
profile-597
/ pid != $target && cpu + 1 == mycpu /
{
        @c[mystack] = count();
}


Chad

Hey Chad,

Moments after the DTrace big bang, we talked about creating stack and
ustack arrays that could be indexed and searched. While there were
many situations where this would have been useful, a true need for
this never materialized.

As you mention, another possibility is to have stack and ustack be
opaque objects that could be saved and passed around like strings.

If either is something you''d be interested in pursuing, I''d be
-- as
always -- happy to work with you.

Adam

On Feb 6, 2009, at 8:00 AM, Chad Mynhier wrote:
> Are there any subtle reasons why DTrace can''t treat stack traces
as
> first-class objects?  They''re already slightly better than
> second-class objects because we can use them as the key to
> aggregations, but we can''t assign them as variables.
>
> (Note, I haven''t looked closely at the code yet to see what would
be
> involved.  I''m mostly curious if this would
break-or-overly-complicate
> things in a manner similar to adding if-then statements.)
>
> What''s driving this is that I want to be able to do application
> profiling, but I want to be able to include a stack trace for when the
> profile probe fires but the application isn''t on CPU.
>
> For example, given a program that does nothing more than
"sleep(10)",
> I can currently see the output of the first command, but what I want
> to see is the output of the second:
>
> # dtrace -n ''profile-597/pid == $target/{@[ustack()] =
count()}'' -
> c ./a.out
> dtrace: description ''profile-597'' matched 1 probe
> dtrace: pid 753689 has exited
>
>
>              libc.so.1`getenv
>              libc.so.1`libc_init+0x5b0
>              ld.so.1`rt_thr_init+0x41
>              ld.so.1`setup+0x13be
>              ld.so.1`_setup+0x310
>              ld.so.1`_rt_boot+0x56
>              0x8047e78
>                1
> # ./uprof.d -c ./a.out
>
>              libc.so.1`0xfee633ca
>                1
>
>              ld.so.1`rtld_db_postinit
>              ld.so.1`setup+0x1414
>              ld.so.1`_setup+0x310
>              ld.so.1`_rt_boot+0x56
>              0x8047e7c
>                2
>
>              libc.so.1`__nanosleep+0x7
>              libc.so.1`sleep+0x31
>              a.out`main+0xf
>              a.out`_start+0x7d
>             5970
> #
>
> Where the code for uprof.d would look like this (which only works for
> the single-threaded case as written):
>
> off-cpu
> / pid == $target /
> {
>         mystack = ustack();
>
>        /* curcpu could be 0, but we want to use mycpu in predicates.  
> */
>        mycpu = cpu + 1;
> }
>
> on-cpu
> / pid == $target /
> {
>        mystack = "";
>        mycpu = 0;
> }
>
> /*
> * If we''re on-cpu, count this stack trace.
> */
> profile-597
> / pid == $target /
> {
>        @c[ustack()] = count();
> }
>
> /*
> * If we''re not on-cpu, and this is the cpu we last ran on, count
> * our last recorded stack.
> */
> profile-597
> / pid != $target && cpu + 1 == mycpu /
> {
>        @c[mystack] = count();
> }
>
>
> Chad
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

--
Adam Leventhal, Fishworks                        http://blogs.sun.com/ahl