Sun’s Bryan Cantrill still pulls out this old chestnut about why dtrace is supposed to be the one true way of instrumenting a system.

It makes some good points, but goes off on a wild strawman chase at this point:

For us, the answer was so clear that it was almost unspoken: we knew that we needed to develop a virtual machine that could act as a target instruction set for a custom compiler. Why was this the clear choice? Because the alternative — to execute user-specified code natively in the kernel — is untenable from a safety perspective.

This false dichotomy overlooks a third possibility – the one adopted by systemtap. Namely, we don’t run user-specified code natively in the kernel: we run code that is synthesized by our tool. This synthesized code includes much the same control/data checks as the dtrace virtual machine has to have. Actually, it has more, since our input scripting language is significantly more expressive.

Accepting these facts, one would have to dig deeper for essential differences – and deeper yet to exclude those that represent bugs and incomplete work rather than architectural limitations. But such a comparison takes more work.