[erlang-patches] DTrace patch, review draft #3

[Scott Lystig Fritchie]

Patrik Nyblom <pan@REDACTED> wrote:

pn> Ouch - guess I should have told you I was starting to work on this a
pn> few days ago - I (with the help of Bjorn-Egil) did the same rebase
pn> as You now have done and started figuring out how to make a hack for
pn> the io-stuff that will affect the non-dtrace version less. I'll take
pn> a look at your rebase and see what we'we missed!

Hej, that's alright.  When I saw the merge conflict, I was afraid that
I'd also have to fix up the protocol junk between prim_file.erl and
efile_drv.c.  That was a depressing thought, so I avoided it for weeks.
When I finally took a close look, the fear was unfounded, hooray.

So, I believe that all the changes between dtrace-review3 and the
dtrace-review4* branches can be seen on the dtrace-experiment+michal2
branch, between these commits:

    adbfd650334d97e02c1290fe5ce6e433c75746e5
    0d30b9356e56acacd144c758cfabacca60d0b110

The dtrace-experiment+michal2 branch is based on R14B, so there are
conflicts when applying them to R15B.  There's also the possibility that
I missed something when applying to R15B.  There request/requirement
that everything be squashed down to only 4 commits and that the 4
commits have no overlapping files ... has caused me headache and
occasional swearing at git.

pn> Anyway, except for the fact that I let you do a rebase work that was
pn> already in some parts done (*blush*), I'm glad to inform you that we
pn> are working on getting the dtrace support upstream for the next
pn> service release. Unless something horrible happens, I see no reason
pn> for this to fail.

That is very, very good news.

We (meaning Basho Technologies) have had the "dtrace-r14b04" branch
running in production on a customer's 60 node Solaris cluster for the
last several weeks.  We are only very infrequently using the Erlang VM
USDT probes, so it's possible that a bug somethere could cause a crash
when the probe is enabled.  But that cluster has been serving over 1
billion Riak requests per day, and that has given us a lot of confidence
that nothing is badly broken.  ^_^

pn> I'm working on a solution where a mechanism similar to sequential
pn> tracing will make the dtrace user tag follow messages through the
pn> i/o-system. If I succeed, almost all changes to the erlang code that
pn> was there to manage the complexity of the i/o-system would
pn> disappear. I have great hopes for this :) I'll push a branch for you
pn> to look at as soon as I have something useful!

I look forward to seeing it!

-Scott