DTrace can monitor events within binary applications without modifying the production application. This capability uses existing DTrace probes. In the case of an application executed by a Virtual Machine (VM), for example Erlangs VM (erts), DTrace events will relate to the underlying Erlang VM, and not directly to the Erlang program being executed by the VM. This makes it difficult for end-application developers, testers and administrators to apply DTrace. These constraints are especially debilitating when Erlang is used within an heterogeneous technology architecture where there are few realistic alternatives to DTrace.

The scope of the Erlang DTrace project is to create DTrace providers, integrated into the Erlang VM, which will provide DTrace events which are easily related to the running Erlang application, and the VM-mediated events such as garbage collection or process scheduling.

Based on our initial investigation of the Java VM, and Ruby VM DTrace providers, the candidate events from Erlang DTrace include:

• Function call and return,
  
• Message send and receive,
• Exception throw and catch,
• Process creation, scheduling and termination,
• Register and unregister name for a Port or PID, 
• Developer-defined probe (which provides an event when called in the Erlang code)
  
• Garbage collection begin and end (there may be other collection events),
• Module load and unload (which may be useful but subtle to implement and use because Erlang can handle two modules simultaneously)

The initial plan is to become comfortable reading the code for the relevant areas using Bjorn Gustavsson's suggestions:

• Erlang trace facility - Henry Nystrom pointed out that is already built, and so may be a relatively self contained/isolated change
• Erlang garbage collector - these events may help me in my benchmarking to see why some pieces have very big latency
• Erlang scheduling (status changes of Erlang processes) - these events should be helpful to show impact of internal & external events, and, on a Mac would allow for a view like the R12 tool, Percept, but with a system-wide mix of Erlang and non-Erlang processes.
• Erlang send/receive - this may fall out of a previous piece, so may be last, but appears to provide a key piece of the jigsaw

This list will be updated as we progress.