Hi, This question is for the dtrace designers and it is something I have been wanting to ask for sometime now. :) Dtrace disallows loops in dtrace scripts. This is with safety in mind. I get that. But has allowing it been considered while in destructive mode? Isn''t destructive mode for things like this - where safety is not guaranteed?? Is the fact that loops can exist in the ''dtrace virtual machine'' instruction set (even though they are allowed only in destructive mode) by itself too dangerous to permit? I tend to think it should be possible. I am a developer and never deal with production systems. The ability to have loops, while in destructive mode, would be something I really would like... Regards, Manoj
On 4/9/06, Manoj Joseph <Manoj.Joseph at sun.com> wrote:> Hi, > > This question is for the dtrace designers and it is something I have > been wanting to ask for sometime now. :) > > Dtrace disallows loops in dtrace scripts. This is with safety in mind. I > get that. > > But has allowing it been considered while in destructive mode? Isn''t > destructive mode for things like this - where safety is not guaranteed?? > > Is the fact that loops can exist in the ''dtrace virtual machine'' > instruction set (even though they are allowed only in destructive mode) > by itself too dangerous to permit? I tend to think it should be possible. > > I am a developer and never deal with production systems. The ability to > have loops, while in destructive mode, would be something I really would > like... >They were deemed unsafe so totally not supported by dtrace, most if not all tasks can be done without loops, it may take more time and thought, but its worth it in the end. I have seen what loops and other non safe concepts, can do in a dtrace "like" environment, Systemtap, linux''s attempt at cloning dtrace, it allows unsafe constructs but in the end they have been working on there project for over a year and they are no where near as stable and robust as dtrace was 2 years ago. They talk about how systemtap can be used to debug problems but hardly anyone uses it for those purproses. If you allow unsafe constructs in your debugging tool, you end up debugging the tool not your application. If there are tasks or problems you need help solving with dtrace post to this list and someone will be able to help you do it safely with in dtrace as it is. James Dickens uadmin.blogspot.com> Regards, > Manoj > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org >
On Sun, 9 Apr 2006, Manoj Joseph wrote:> Hi, > > This question is for the dtrace designers and it is something I have been > wanting to ask for sometime now. :) > > Dtrace disallows loops in dtrace scripts. This is with safety in mind. I get > that. > > But has allowing it been considered while in destructive mode? Isn''t > destructive mode for things like this - where safety is not guaranteed?? > > Is the fact that loops can exist in the ''dtrace virtual machine'' instruction > set (even though they are allowed only in destructive mode) by itself too > dangerous to permit? I tend to think it should be possible. > > I am a developer and never deal with production systems. The ability to have > loops, while in destructive mode, would be something I really would like...Brendan actually came up with an ingenius way to loop over items; check out zvmstat in the DTraceToolkit for additional details. Is there a reason you can''t wrap massuage your data with perl / shell? Thanks, - Ryan -- UNIX Administrator http://daemons.net/~matty
James Dickens wrote:> If you allow unsafe constructs in your debugging tool, you end up > debugging the tool not your application.I guess I agree with the above statement in general. But I don''t necessarily agree with it with respect the halting problem. If the halting problem is what is being avoided, my take is that it is worth permitting in destructive mode.> If there are tasks or problems you need help solving with dtrace post > to this list and someone will be able to help you do it safely with in > dtrace as it is.Printing the arguments of a function with "argc, argv" kind of arguments is something that comes to my mind. I have been using dtrace and I keep falling in love with it everytime I use it to solve a problem. And I have been able to workaround cases when I could have used a loop. But a workaround is a workaround and sometimes you just do without what you would have liked to do. You know, people did debug and tune systems in the days prior to dtrace. ;) Manoj
>James Dickens wrote: >> If you allow unsafe constructs in your debugging tool, you end up >> debugging the tool not your application. > >I guess I agree with the above statement in general. But I don''t >necessarily agree with it with respect the halting problem. > >If the halting problem is what is being avoided, my take is that it is >worth permitting in destructive mode.There are also bounded loops such as, e.g., "mapcar" type operations.>Printing the arguments of a function with "argc, argv" kind of arguments >is something that comes to my mind.There might be an awful lot of those. Casper
Roch Bourbonnais - Performance Engineering
2006-Apr-10 09:18 UTC
[dtrace-discuss] Loops in dtrace
Casper.Dik at Sun.COM writes: > > >James Dickens wrote: > >> If you allow unsafe constructs in your debugging tool, you end up > >> debugging the tool not your application. > > > >I guess I agree with the above statement in general. But I don''t > >necessarily agree with it with respect the halting problem. > > > >If the halting problem is what is being avoided, my take is that it is > >worth permitting in destructive mode. > > There are also bounded loops such as, e.g., "mapcar" type operations. > > >Printing the arguments of a function with "argc, argv" kind of arguments > >is something that comes to my mind. > > There might be an awful lot of those. > > Casper So it does appear that a bounded loop construct would not jeoperdize the availability of a system. The other issue that Dtrace would have to deal with is that probe enablings must generate a fixed amount of raw data (data prior to formatting my dtrace(1M)). That would mean that probe enabling with a loop construct would have to size their buffers based on a fixed max loop count (not a dynamic one). So would a loop construct that maxes out at say 8 iterations still be valuable ? ____________________________________________________________________________________ Roch Bourbonnais Sun Microsystems, Icnc-Grenoble Senior Performance Analyst 180, Avenue De L''Europe, 38330, Montbonnot Saint Martin, France Performance & Availability Engineering http://icncweb.france/~rbourbon http://blogs.sun.com/roller/page/roch Roch.Bourbonnais at Sun.Com (+33).4.76.18.83.20
On Mon, 10 Apr 2006, Roch Bourbonnais - Performance Engineering wrote:> So would a loop construct that maxes out at say 8 iterations > still be valuable ?I think this would be immensely valuable. - Ryan -- UNIX Administrator http://daemons.net/~matty
On Mon, Apr 10, 2006 at 10:28:20AM -0400, Matty wrote:> > On Mon, 10 Apr 2006, Roch Bourbonnais - Performance Engineering wrote: > > >So would a loop construct that maxes out at say 8 iterations > >still be valuable ? > > I think this would be immensely valuable.Why not just unroll the loop, in those minimal cases where it might be necessary? i.e.: fbt::foo:entry { this->argc = arg0; trace(this->argc); trace((this->argc > 0)? arg1 : 0); trace((this->argc > 1)? arg2 : 0); trace((this->argc > 2)? arg3 : 0); trace((this->argc > 3)? arg4 : 0); trace((this->argc > 4)? arg5 : 0); trace((this->argc > 5)? arg6 : 0); trace((this->argc > 6)? arg7 : 0); trace((this->argc > 7)? arg8 : 0); } Something similar to this can be done in all "max 8-iteration" loops. If you really want to record a variable amount of data, that''s easy: fbt:::foo:entry { this->argc = arg0; trace(this->argc); } fbt:::foo:entry /this->argc > 0/ { trace(arg1); } fbt:::foo:entry /this->argc > 1/ { trace(arg2); } fbt:::foo:entry /this->argc > 2/ { trace(arg3); } fbt:::foo:entry /this->argc > 3/ { trace(arg4); } fbt:::foo:entry /this->argc > 4/ { trace(arg5); } fbt:::foo:entry /this->argc > 5/ { trace(arg6); } fbt:::foo:entry /this->argc > 6/ { trace(arg7); } fbt:::foo:entry /this->argc > 7/ { trace(arg8); } Cheers, - jonathan -- Jonathan Adams, Solaris Kernel Development
G''Day, On Mon, 10 Apr 2006, Jonathan Adams wrote:> On Mon, Apr 10, 2006 at 10:28:20AM -0400, Matty wrote: > > > > On Mon, 10 Apr 2006, Roch Bourbonnais - Performance Engineering wrote: > > > > >So would a loop construct that maxes out at say 8 iterations > > >still be valuable ? > > > > I think this would be immensely valuable. > > Why not just unroll the loop, in those minimal cases where it might > be necessary? i.e.: > > fbt::foo:entry > { > this->argc = arg0; > trace(this->argc); > trace((this->argc > 0)? arg1 : 0); > trace((this->argc > 1)? arg2 : 0); > trace((this->argc > 2)? arg3 : 0); > trace((this->argc > 3)? arg4 : 0); > trace((this->argc > 4)? arg5 : 0); > trace((this->argc > 5)? arg6 : 0); > trace((this->argc > 6)? arg7 : 0); > trace((this->argc > 7)? arg8 : 0); > }While this looks inelegant, I completely agree, and have done this more than once. Matty mentioned I had another solution to this in zvmstat (a feedback loop), which is certainly interesting to note but not really a great idea. If possible, unroll. Of course, it''s oblagatory to mention Duff''s device when talking about unrolled loops. http://en.wikipedia.org/wiki/Duff''s_device :) Brendan