Solution/Nugget: D-Trace provides a uniform, extensible API for instrumenting both kernel and user level behavior, letting the same tracing program access both. The D programming language for tracing scripts is also a novel contribution because it supports high-level programming constructs and easy access into kernel variables while keeping tracing code "safe".
Differences from previous work: D-Trace mostly differs because it combines a number of good ideas and good engineering practice. There were other systems that did particular pieces of D-Trace, but D-Trace managed to combine these into a single framework upon which a lot of instrumentation can be built.
Tradeoffs: There are certainly some tradeoffs mentioned between tracing performance, safety and power to collect data. D-Trace tries to enable the most types of analysis while providing strict guarantees for performance and safety. The language contains constructs like aggregates to make this easier.
One other aspect, which may or may not be a tradeoff, is that D-Trace is designed to be an "interactive" tool where you write a trace program for just the events you care about and run it. Other systems, like X-Trace, try to be a "capture" tool where you analyze data after the fact. This makes D-Trace fast and flexible but means that it cannot be used for post-mortem analysis of a problem. This is why the paper focuses on performance problems mostly (which occur chronically).
Will it be influential? Hopefully. It would be really great to have this as a standard API in Unix-like OSes. Right now D-Trace is one of the main advantages of using Solaris but can't be used in Linux because the license conflicts with the GPL.
1 comment:
Nice observation about the of-line vs. on-line (i.e., postmortem) analysis! However, I do not think they are exclusive, though clearly postmortem analysis requires exhaustive tracing.
Post a Comment