Hi all,

There's a dead thread about this back at 
http://forums.sun.com/thread.jspa?threadID=5075157, but it would be really nice 
to have support for if/else control flow in actions. 

Reasons: 
1. The ternary operator ?: is already there (though it doesn't let you do 
anything with side effects)
2. The user can already write arbitrary and expensive non-cacheable predicates 
if they want, so performance shouldn't go down as a result.
3. For performance reasons it would be nice to push expensive non-cacheable 
predicates inside the action so the cacheable ones can still do their job 
efficiently (see http://docs.sun.com/app/docs/doc/817-6223/chp-perf-3?a=view)

For example, I have a dtrace script that prints out a message whenever a thread 
gets preempted during certain (< 1usec long) critical sections. To avoid the 
overhead of invoking dtrace every time they enter/exit (~6usec), at thread 
startup they pass dtrace a pointer to a variable which they can then update 
directly; dtrace checks it during context switches:

sched:::off-cpu
/ pid == $1 && self->user_ptr != 0 && *(int*) copyin(self->usr_ptr, 
sizeof(int)) != 0 /
{
/* print notification message */
}

The first two predicates are cacheable and eliminate virtually all of the 
threads in the system, while the third predicate is uncacheable and only 
required occasionally. To minimize the cost of this probe it would be very nice 
to be able to write:

sched:::off-cpu
/ pid == $1 && self->user_ptr != 0 /
{
if( *(int*) copyin(self->usr_ptr, sizeof(int)) != 0)
    /* print notification message */
}

Alternatively, a smarter compiler might push expensive non-cached predicates 
inside the action without exposing any API changes to the user. That might 
actually be better because then the user can write predicates without having to 
worry quite so much about whether they're cacheable or not.
--
This message posted from opensolaris.org
_______________________________________________
dtrace-discuss mailing list
[email protected]

Reply via email to