Anyway, because we had low overhead breakpoints that could run code, the technique I used instead of further investment in specialized instrumentation
was to use breakpoints that ran code to log/collect information. It was higher overhead and more manual, but also much more flexible, so it was a better answer.
So the answer I picked _was_ to do more of it in Lua and OP_HALT was what made that viable whereas the debug.hook based solutions imposed too much overhead to get accurate results. It is actually still dtrace-like, but our regular code/logging breakpoints instead of a new type of tracing breakpoint.
"Trace points" were starting to prove very handy as a quick/dynamic (and very low overhead) way to measure time/paths taken in certain segments of code that were executing. Combined with our low overhead sampling profiler's more holistic view of which code was running when pausing periodically, it could save a lot of time quantifying the costs/distributions of different code paths of particular interest. The two approaches (top down and bottom up) were proving complementary.