Erlang function parameters
G Bulmer
few things, including:
1. Make it easy to identify the events they need to observe and
record, and
2. Make it easy to copy Erlang values into D script variables.
Ignoring point 1 for now, and focusing on 2 ...
I've been thinking about the ways that DTrace D scripts use program
information; specifically how D scripts use data from a user
application, made available to it via DTrace probes, in D script
actions.
For example, it is common to correlate events across lots of calls
using a bit of program data. Concretely, a D script may observe a set
of system calls, but to make the observations more useful, it may
need to only record information for a specific file descriptor. This
is very easy to do with DTrace because function and system call
parameters are available to the D script, and those values can be
*copied* into D script variables for use in later actions. It is very
common to see a D variable being compared with a user-level function
parameter as part of a guard to a D script action. In this concrete
example, the actions only trigger if the file descriptor matches the
one being observed.
D script supports any types available in C. It doesn't support some
Erlang datatypes, for example lists, ports, PIDs.
Initial proposal: convert Erlang-unique datatypes to C-style '\0'
terminated strings (which are supported in D), using Erlang's
formatting functions.
Rationale: DTrace supports C-strings, so comparison will work, the
Erlang values are available to D scripts in a consistent format, so
filtering, correlation, etc all work fine. Importantly D associative
arrays work with strings, so the same value, in different variables
will match.
Concerns: imposes runtime overhead, which is best avoided if DTrace
is to be 'cheap' to use.
Other benefits: It should be easy to debug.
Alternative proposal: use references (pointers) for Erlang-unique
datatypes.
Benefits: likely to impose a minimal time and space overhead, which
is consistent with DTrace.
Concerns: Erlang garbage collection may 'move' pointers (i.e. move
the values pointed to), so that correlation etc. breaks. It may be
hard to debug as GC may be non-deterministic.
Mitigation action: find out if a pointer to a value *can* change,
because if it can't it may provide optimal performance.
Best of all worlds: where practical provide both reference based
interfaces, and string based interfaces, so that D scripts can 'have
it all'.
Does this make sense?
Garry
Tim
> Does this make sense?
It makes perfect sense and I think the parameterization of the probes,
i.e. the probe interfaces/prototypes, whatever one cares to call them
are rather important so it'll require some effort to define them
properly.
I don't have much time at the moment because I still need to do some
christmas shopping (arrgh!) so here's some random thoughts on the
matter:
* you already brought up a lot of points to pay attention to
concerning access to erlang data. Another problem I've encountered
thinking about this is that a lot of the datatypes used in Erlang
would be difficult to deal with from D even if mapping between Erlang
and C data doesn't turn out to be difficult. E.g. I'd hate to have to
traverse a linked list in D and those will pop up all over.
The Erlang tracing mechanism allows to types of function call tracing,
one send {Module, Func, Args} messages and the other {Module, Func,
Arity}
* There's a lot of support code for converting Erlang datatypes to C
usable data scattered throughout erts already, I think that would be
something well worth cataloging to avoid reinventing the wheel.