Hi all, Is there any kind of specification that probes from the same script fire in the order they were declared (modulo predicates, of course)? Google turned up a ppt from 2005 which suggests they do, but there''s nothing in the docs about it. Simple tests suggest that the probes fire in order, but things have a way of changing once the script gets more complex or the system more loaded... Order-preserving dtrace would - allow as elaborate if-then-else control flow as one is willing to write and debug - simplify pointer chasing when each pointer along the way could be NULL - preserve predicate caching (especially good if most of the branching occurs only rarely) The alternative is to abuse the ternary ?: operator and try to make DTrace into a functional language (yuck!). Does anyone know the official spec on this? Thanks! Ryan -- This message posted from opensolaris.org
On Sat, Apr 18, 2009 at 9:25 AM, Ryan <ryanjohn at ece.cmu.edu> wrote:> Hi all, > > Is there any kind of specification that probes from the same script fire in the order they were declared (modulo predicates, of course)? Google turned up a ppt from 2005 which suggests they do, but there''s nothing in the docs about it.Yes, probes from the same script fire in the order they were declared. I don''t know that there''s an official spec that says that this is how it must be, but that''s how it is. An enabled probe has a linked list of ECBs (enabling control blocks) attached to it. Each ECB corresponds to a clause in the D script and contains (among other things) a pointer to a dtrace_predicate_t and a pointer to a list of dtrace_action_t''s. These each contain the intermediate-format code that''s run when the probe fires. First the code for the predicate is run, and if that evaluates to true, the code in each node in the list of actions is run. So when a probe fires, dtrace_probe() walks the linked list of ECB''s, executing each clause in the order they show up in the list. The linked list was created in the same order in which those clauses appeared in the D script, so yes, the probes from the script fire in the same order they were declared. Chad The linked list of ECBs is When a D script is compiled,
On Sat, Apr 18, 2009 at 10:45 AM, Chad Mynhier <cmynhier at gmail.com> wrote:> > Chad > The linked list of ECBs is > When a D script is compiled, >Ignore the garbage after the signature. :-)
Yes clauses execute in order and that''s both by design and a behavior that is part of the D language specification (though perhaps implicitly). If there''s a documentation change that would clarify this please propose it and then make the change on the wiki. - ahl [$] On Apr 18, 2009, at 6:25 AM, Ryan <ryanjohn at ece.cmu.edu> wrote:> Hi all, > > Is there any kind of specification that probes from the same script > fire in the order they were declared (modulo predicates, of course)? > Google turned up a ppt from 2005 which suggests they do, but there''s > nothing in the docs about it. > > Simple tests suggest that the probes fire in order, but things have > a way of changing once the script gets more complex or the system > more loaded... > > Order-preserving dtrace would > - allow as elaborate if-then-else control flow as one is willing to > write and debug > - simplify pointer chasing when each pointer along the way could be > NULL > - preserve predicate caching (especially good if most of the > branching occurs only rarely) > > The alternative is to abuse the ternary ?: operator and try to make > DTrace into a functional language (yuck!). > > Does anyone know the official spec on this? > > Thanks! > Ryan > -- > This message posted from opensolaris.org > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org
> Order-preserving dtrace would > - allow as elaborate if-then-else control flow as one is willing to > write and debugAnd that is exactly how you implement if-the-else in DTrace: split your clause into separate clauses, put a predicate at the head of each one to control when the clause applies, and start each clause off with the same probe spec. So when the probe fires, the clauses, controlled by the predicates, will always fire in script appearance order. The only problem is loop control. There are no good ways to do that. You can have a profile probe that fires often enough to give you iterations under predicate control, but you can''t guarantee the iterations will happen fast enough to stay out of the way of changing kernel data, or the next firing of the probe that started the iterations. (Thread-locals will at least keep iterations of the loop from colliding with other threads.) And then there''s using shell scripts to build the DTrace script on the fly. But then you have to know how many iterations you''ll need before the DTrace script is called. One reliable way to do loops is to build enough individual clauses into the script to cover the maximum number of iterations, if you know what that is, and it is a reasonable number. But this was not your original question, and I digress.... Chip
> Yes clauses execute in order and that''s both by > design and a behavior that is part of the D language > specification (though perhaps implicitly). If there''s > a documentation change that would clarify this > please propose it and then make the change on the > wiki. > > - ahlThanks to all for the fast replies! My inclination would be to extend http://wikis.sun.com/display/DTrace/D+Program+Structure#Program+Clauses+and+Declarations as follows: ... a D program source file consists of one or more probe clauses that describe the instrumentation to be enabled by DTrace. ***A single probe description may match multiple providers and a D program may declare multiple probe descriptions matching the same provider. Whenever multiple probes match a provider they fire in the order they were declared in.*** Each probe clause has the general form: To really do it right, though, we should also add a new section, between Actions and CPP, which explains how in-order firing can be exploited to implement control flow, preserve predicate caching when some of the predicates are non-cacheable, etc. It might also point out the gotchas that could come up if you declare clauses in the wrong order and cause unintended control flow (e.g. by accidentally changing a variable some later clause was predicated on). Ryan BTW, I tried replying directly from my mail client, but it bounced... do I need to do something special before sending to the list? -- This message posted from opensolaris.org
On 4/18/09, Ryan <ryanjohn at ece.cmu.edu> wrote:> BTW, I tried replying directly from my mail client, but it bounced... do I need to do something special before sending to the list?Are you subscribed to the list?? Email Action -> http://opensolaris.org/os/community/dtrace/discussions/ Rayson> -- > This message posted from opensolaris.org > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org >
Using Chad''s description above as a base, I propose the following addition to http://wikis.sun.com/display/DTrace/D+Program+Structure. I think it would work well directly below the Actions section: *** Order of Execution Once submitted, each clause is represented by an enabling control block (ECB) that points to the intermediate form of the predicate, if any, and the clause''s actions. The actions execute if the predicate evaluates to true or if no predicate is given. Program order determines the order in which actions are executed. Two or more clauses that enable the same probe will also execute in program order. *** I think a discussion of flow control would fit well in Scripting, and notes on maintaining cacheable predicates would add nicely to the Performance Considerations page. I''m happy to propose such changes if there''s interest in that approach. -- This message posted from opensolaris.org
Hey Michael, That looks fine. You may choose to remove the bit about ECBs since that''s probably extraneous information. Adam On Apr 18, 2009, at 3:00 PM, Michael Ernest wrote:> Using Chad''s description above as a base, I propose the following > addition to http://wikis.sun.com/display/DTrace/D+Program+Structure. > I think it would work well directly below the Actions section: > > *** > > Order of Execution > > Once submitted, each clause is represented by an enabling control > block (ECB) that points to the intermediate form of the predicate, > if any, and the clause''s actions. The actions execute if the > predicate evaluates to true or if no predicate is given. Program > order determines the order in which actions are executed. Two or > more clauses that enable the same probe will also execute in program > order. > > *** > I think a discussion of flow control would fit well in Scripting, > and notes on maintaining cacheable predicates would add nicely to > the Performance Considerations page. I''m happy to propose such > changes if there''s interest in that approach. > -- > This message posted from opensolaris.org > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- Adam Leventhal, Fishworks http://blogs.sun.com/ahl