On Sat, 2008-01-12 at 01:30 +0000, John Levon wrote: > On Fri, Jan 11, 2008 at 04:39:25PM -0800, Roman Shaposhnik wrote: > > > > Due to the lack of ustack helper, I am hoping to add a stack probe > > > > Two things: first of all DTrace could really benefit from a > > general purpose mechanism of hooking up custom stack helpers > > with the rest of the system. Frankly, the way jstack is done > > doesn't strike me as too generic a mechanism. > > Do you have something in mind?
Discalimer: I can't really claim to be an expert in DTrace, my main familiarity with it comes from working on a tool that sometimes pushes DTrace to its limits and that way I'm forced to explore how these limits could be overcome. If what I have to say below is a wrong perception of the technology I'd love to be educated by the subject experts. My main beef with stack helpers is that they have to be executed inside the kernel and are subject to the usual DTrace restrictions. I would like to see a possibility of offloading more work to user space in a generic fashion. For example, we have a libcollector.so facility that is capable of reconstructing stacks under the most challenging of situations (inside the function preamble, etc.) it is way more accurate in what it reports back than ustack() it is also capable of more stack unwinding than jstack(). Of course, it runs in user space. We do have some preliminary ideas on how such functionality can be hooked to the rest of DTrace machinery. If there's a significant portion of the DTrace community that is interested in extending DTrace functionality in a way that would make it more reliant on userspace -- perhaps it is a good thing to have on the DTrace conference agenda. Thanks, Roman.
