dtrace.conf(12) wrap-up
Bryan provided a typically eloquent review of the state of the community. DTrace development is alive and well -- after a lull while Oracle's acquisition of Sun settled in -- with new support for a variety of languages and runtimes, and new products that rely heavily on DTrace as a secret sauce. Bryan laid out some important development goals, areas where many have started straying from the edges of the completed DTrace features into the partially complete or starkly missing. We all then set to work hammering out a loose schedule for the day; I'll admit that at first I was worried that we'd have too many listeners and not enough presenters, but the schedule quickly filled -- and with more topics than we'd end up having time to cover.
User-land CTF and Dynamic Translators
DTrace, from its inception, has been a systemic analysis tool, but the earliest development focused on kernel observability -- not a surprise since Bryan, Mike, and I developed it while working in the Solaris kernel development. After its use spread (quickly) beyond the kernel team, use shifted more and more to features focused on understanding C and C++ applications in user-land, and then to applications written in a variety of higher-level languages -- Java, Ruby, Perl, Javascript, Erlang, etc. User-land Statically Defined Tracing (USDT) is the DTrace facility that enables rich tracing of higher-level languages. It was a relatively late addition to DTrace (integrated in 2004, well after the initial integration in 2003), and since then we've learned a lot about what we got right, what we got wrong, and where it's rough -- in some cases very rough -- around the edges.
In his opening remarks, Bryan identified USDT improvements as a key area for the community's focus. In DTrace development we tried to focus on making the impossible possible rather than making the possible easier. In its current form, some things are still impossible with DTrace, namely consumption of type structures from user-land programs; stable, non-privileged use of DTrace; and support for different runtime versions. Dave Pacheco and I took the first slot on the schedule and spoke (at length -- sorry) about solutions to these problems.
While others had the benefit of a bit more time to prepare, I did have the advantage of spending many years idly contemplating the problem space and possible solutions. On the subject of user-land type information (in the form of CTF), I identified the key parts of the code that would would need some work. For the USDT enhancements, we discussed dynamic translators -- D code that would be linked and executed at runtime, contrasted with today's static translators that are compiled into a D program -- how they would address the problem, and how these ideas could be extended to the kernel (for once, user-land is actually a bit ahead).
I'll go into the details of our off the cuff proposals, and delve into the code to firm up those ideas in a future blog post. Beyond the extensive implementation work we laid out, the next step is to gather the most complicated, extant USDT providers and proposals for other providers, and figure out what they should look like in the new, dynamic translator world.
The D Language
Next up, my long-time colleague, DTrace contributor, Eric Schrock led the discussion on D language additions. The format of a D program is heavily tied to DTrace's implementation: all clauses must trace a fixed amount of data, and infinite loops are forbidden. For this reason, D lacks the backward branches needed for traditional looping, subroutines for common code, and if/else clauses for control flow. Each of these has a work-alike -- unrolled loops, macros, and predicates or the ternary operator -- but their absence renders D confusing to some -- especially those unaware of the motivation. Further, the D language need not necessarily hold the underlying implementation so central.
Eric discussed some proposals for how each might be addressed, and I noted that it would be possible to create a prototype environment where we could try out these "D++" features by compiling into D work-alikes. The next step is to identify the most complicated D scripts, and see what they might look like for various incarnations of those language features.
Work with DTrace
The next few sessions focused not on changes to DTrace, but interesting work done using DTrace:
John Thompson of Sony talked about their port of DTrace to the Playstation Vita (!). Sony developers are given access to DTrace, but found it to be unfamiliar and unapproachable. John spoke his attempts to remedy this by replacing D with a C++-like interface which he implemented by replacing the D compiler with Clang.
My Fishworks colleague, Brendan Gregg, showed some of beautiful visualizations they've been developing at Joyent, and talked about the analyses those visualizations enabled. As always, it was fascinating stuff. If you don't read Brendan's blog, you really should. Long-time DTrace advocate, Theo Schlossnagle, talked about the visualizations they're doing in Circonus -- also fascinating stuff for anyone thinking about how to present system activity in comprehensible ways. Richard Elling showed the DTrace-based visualizations Nexenta used at VMworld to rave reviews.
Mark Cavage presented Joyent's work bringing DTrace to node.js; Scott Fritchie talked about DTrace for Erlang. Both were useful sources of ideas for how we could improve USDT.
Ryan Stone presented the state of DTrace on FreeBSD. That DTrace is not enabled in the build by default remains a key obstacle for adoption. I hope that Ryan et al. are able to persuade the FreeBSD leadership that their licensing fears are misguided.
DTrace for OEL
I was delighted that Kris van Hees was able to attend to present the Oracle port to Linux. DTrace for OEL was announced at Oracle Open World 2011, but the initial beta didn't live up to its billing at OOW. As is often the case, this was more a failure of messaging than of engineering. Kris and his team are making steady progress. While it's not yet in the public beta, they have the kernel function boundary tracing provider (fbt) implemented. Most heartening of all, Oracle intends to keep DTrace for OEL moving forward as the community evolves and improves DTrace -- rather than forking it. How that plays out, and what that means for DTrace on Oracle Solaris will be interesting to see, but it's great to hear that Kris sees the value of DTrace ubiquity and DTrace compatibility.
As was remarked several times, having DTrace available on the fastest growing deployment platform will be the single most significant accelerator for DTrace adoption. The work Kris and his team at Oracle are doing is probably the most important in the DTrace ecosystem, and I think that I speak for the entire DTrace community in offering to assist in any way possible.
A ZFS DTrace Provider
Matt Ahrens and George Wilson -- respectively the co-inventor of ZFS, and the preeminent SPA developer -- presented a proposal for a DTrace provider for ZFS. ZFS is a highly sophisticated filesystem, but one that is also difficult to understand. Building in rich instrumentation is going to be a tremendous step forward for anyone using ZFS (for example, our mutual employer, Delphix).
Whither DTrace?
Jarod Jenson -- the first DTrace user outside of Sun -- took the stage in the final session to talk about DTrace adoption. Jarod has made DTrace a significant part of his business for many years. What continues to amazing him, despite numerous presentations, demonstrations, and lessons, is the relatively low level of DTrace adoption. DTrace is a tool that comes alive in the hands of a skilled, scientific, incisive practitioner -- and in all of those, Jarod is superlative -- but it can have a high bar of entry. There were many concrete suggestions for how to improve DTrace adoption. Most of them didn't hold water for me -- different avenue for education, further documentation, community outreach, higher level tools, visualizations, etc. -- but two were quite compelling: DTrace for Linux, and DTrace on stackoverflow.com (and the like). I don't know how much room there is to participate in the former, but by all means if there are DTrace one-liners that solve problems (on Mac OS X for example), post them, and get people covertly using DTrace.
The core DTrace community is growing. It was great to see old friends like Steve Peters who worked on porting DTrace to Mac OS X in the same room as Kris van Hees as he spoke about his port to Linux. It was inspiring to see so many new members of the community, eager to use, build and improve DTrace. And personally it inspired me to get back into the code to finish up some projects I had in flight, and to chart out the course for some of the projects we discussed.
Thanks to everyone who attended dtrace.conf in person or online. And thanks especially to Deirdre Straughan who made it happen.
- ← Previous
DTrace OEL update - Next →
BTrace: DTrace for Java... ish