Erlang and DTrace thread local storage
G Bulmer
the effort to implement will be disproportionately high compared to
the benefit. But I felt I should record the idea, and our rationale
for posterity -
DTrace has several powerful features. One is thread local variables.
This is about making them work for Erlang DTrace.
The fundamental questions are:
1. Are there significant benefits to mapping Erlang processes to
DTrace thread local variables?
2. Is it feasible to map Erlang processes to DTrace thread local
storage, and would it scale?
3. Would we be forced to give up some other benefit?
Any D script can handle native OS threads. Within the D script the
'current thread' is known, and can implicitly use thread local
variables as self->variable1, self->variable2 etc. Hence the D script
can record the behaviour of each thread, and the D script is
relatively easy to write.
So, for example, a D script could count how any times a thread
executes a specific function, logically:
provider:module:function:entry { self->funcount++ }
and this would capture the count for each individual thread which
triggers the probe.
Thread local variables could be simulated using an array for each
variable, by using the thread id as an index (in the Erlang case,
it'd be the Erlang process Id):
... variable1[threadId] ...
So, the first questions is more accurately: Are there significant
advantages to using thread local variables over simulating them with
arrays? (Advantages significant enough to justify the effort :-)
Erlang implements it's own concept of process. So part of the second
question is: could the Erlang process be mapped onto DTrace's thread
concept, or is the DTrace mechanism too complex or beyond our reach?
Erlang has very light weight processes, reputedly less than 200
bytes. There are production Erlang systems which use more than 10,000
Erlang processes, and some people at Ericsson expect to have
production systems with over 100,000 Erlang processes very soon. I do
not know how DTrace implements thread local storage, but a further
part of question two is: would DTraces thread local storage mechanism
scale to 10,000+ 'threads', or would it be too dangerous or expensive
to use?
Finally, Erlang's use of the type of OS threads visible to DTrace is
(I believe) internal to the VM, and does not relate to the Erlang
concept of process. It may be useful to observe using DTrace those
internal VM uses of OS threads. So the final question is: if DTrace
thread local storage was mapped to Erlang processes would we lose the
ability to also use DTrace thread local storage to observe the Erlang
VM's use of threads? My gut says 'no', we would just have more types
of probe, but the point should be noted to remind us to think things
through.
GB-)
PS - Sorry of this seems 'obviously bad', but I believe a lot of
engineering effort gets wasted rehashing the same ideas, so this is
my small effort to minimise waste :-)