Is anyone working on building an Erlang DTrace provider? I realise DTrace isn''t available on all Erlang platforms, but now that DTrace is available Mac OS X (Leopard), as well as Solaris (and FeeeBSD?), I feel it might be worth doing. I assume everyone here understands DTrace, so I won''t dig into that. So I hear you ask, why build a DTrace provider for erl when DTrace already works (on Solaris and Leopard) with erl? Well, DTrace will show which functions are called in the Erlang runtime (erts) (and which file descriptors and sockets are used, etc.), but will *not* show the Erlang script''s activity and events directly. A comparable model is Java. The JVM implement a DTrace provider, which surfaces Java method calls, class loading/unloading, the garbage collector, concurrency monitors etc. (rather than the details of the JVM program, which are available anyway). So, I am suggesting an erts DTrace provider would show similar things, specifically: - module loading/unloading (this is a very important part of the Erlang runtime as it can load new modules without stopping the application), - function calls (and exits, though tail-recursive calls are compiled to iteration), - garbage collection events (this would need to identify the effected Erlang processes, as the heaps are local to those processes), - Erlang-process state/context-switching, - message send/receive. This would likely be sufficient when combined with the existing DTrace support for tracing TCP and UDP sockets, file access etc from the erts process. There is some dynamic tracing support in the Erlang runtime (erts), so part of this may be a relatively small effort for someone who knows there way around the Erlang VM. As you all probably know, Mac OS X ''Leopard'' comes with a fancy GUI to show DTrace events along a common time line, so that would give something like the new Erlang Percept tool (included in the next Erlang R12 release) but for many different types of event, not just process state. I believe when building and deploying large, complex system, availability of DTrace would be an important consideration, and that is Erlang''s sweet spot. IMHO, DTrace is so useful, that the Erlang developers and maintainers may find it extremely useful for debugging, testing, and tuning Erlang itself. I don''t have the time, or familiarity with erts, to do this in the near term, but is anyone out there looking at/doing this? G Bulmer