nsProbes design

[Vladimir Vukicevic]

For quite a while I've wanted the ability to stick in probes at various
points in the code. Some of this overlaps with the dtrace work in bug
370906 -- however, that work depends on dtrace which is not available on
win32. Hopefully this approach can share probes with the dtrace work,
so that the same probe declarations can work with both systems to avoid
the need to instrument code twice.

I've put together a design and some code for a first pass. Some of the
use cases overlap with the old timeline code; some of the use cases
(very slightly) overlap with nspr logging. The goals are:

- high performance
- no impact if no event capture is occurring
- minimal impact if events are being captured
- data collection
- event ranges (event start .. event end)
- timestamps
- counters
- strings (UTF8 and UTF16), arbitrary ints

The idea is that each probe will be its own datastream, with each probe
trigger being sequential in time. Only some of the probes include an
explicit timestamp; the others are assumed to be ordered by probes that
came before and that come after it. With this data I'd like to be able
to visualize what's happening in detail during, for example, loading of
a certain page, to give us an idea of what areas we should be focusing
on for performance work. For example:

/* in nsWindow.cpp */
NS_PROBE_DECLARE_REGION(widget_OnPaint);

...
OnPaint() {
NS_PROBE_TRIGGER_REGION(widget_OnPaint);

/* ... probe automatically sends an end at the exit of OnPaint */
}

/* in <notsurewhatfile> */

NS_PROBE_DECLARE_STRING(net_LoadGroupStart);

...
StartLoadGroup() {
NS_PROBE_TRIGGER(net_LoadGroupStart, baseUrl);
...
}

We'd get a region start/end every time we enter/exit OnPaint (the
regions are numbered, so recursive entries into a function are recorded
correctly), and we'd get the string of the loadgroup whenever we start
loading a page. Along with other probes (e.g. timestamps for network
load start/end, a timestamp probe for when we fire onload, etc), this
would give a view into what's going on, both for performance analysis
and potentially for bugfixing purposes.

The implementation right now writes to a file whenever an in-memory
buffer is filled. This is far from ideal; it was done for simplicity.
The next step is probably to start a writer thread that's reading
buffers from a lock-free FIFO and writing them to disk. After that, I'd
like to be able to send the buffer via a pipe directly to another
application that can visualize the probes in real time.

I'll post a bug number and a patch shortly; any initial feedback on this
approach?

- Vlad