They're really very different -- with very different origins and constraints. If you want to hear about my own experiences with bpftrace, I got into this a bit recently.[0] (And in fact, one of my questions about the article is how they deal with silently dropped data in eBPF -- which I found to be pretty maddening.)
I listened to this live! That's probably why I was wondering, because I remember you talking about something you used in Linux that didn't quite live up to your expectations with DTrace, but I didn't catch all of the names. Thanks!
By dropped data do you mean by exceeding the size of the allocated ring buffer/perf buffer? If so this is configurable by the user, so you can adjust is according to the expected load
eBPF can drop data silently under quite a few conditions, unfortunately. And -- most frustratingly -- it's silent, so it's not even entirely clear which condition you've fallen into. This alone is a pretty significant with respect to DTrace: when/where DTrace drops data, there is always an indicator as to why. And to be clear, this isn't a difference merely of implementation (though that too, certainly), but of principle: DTrace, at root, is a debugger -- and it strives to be as transparent to the user as possible as to the truth of the underlying system.
I don’t have a lot of experience using dtrace, but AFAIK the big advantage of eBPF over dtrace is that you do not need to instrument your application with static probes during coding.
DTrace (on Solaris at least) can instrument any userspace symbol or address, no need for static tracepoints in the app.
One problem that DTrace has is that the "pid" provider that you use for userspace app tracing only works on processes that are already running. So, if more processes with the executable of interest launch after you've started DTrace, its pid provider won't catch the new ones. Then you end up doing some tricks like tracking exec-s of the binary and restarting your DTrace script...
That's not exactly correct, and is merely a consequence of the fact that you are trying to use the pid provider. The issue that you're seeing is that pid probes are created on-the-fly -- and if you don't demand that they are created in a new process, they in fact won't be. USDT probes generally don't have this issue (unless they are explicitly lazily created -- and some are). So you don't actually need/want to restart your DTrace script, you just want to force probes to be created in new processes (which will necessitate some tricks, just different ones).
So how would you demand that they’d be created in a new process? I was already using pid* provider years ago when I was working on this (and wasn’t using static compiled-in tracepoints).
