It can also be used for dtrace-like instrumentation points.
Interesting. After mucking around in the VM for the purposes of applying your patch, I've started daydreaming about writing some instrumentation hooks of my own. What I'd like to do is generate a call stack trace + runtime info for a given entry point, so that I can more easily track down runtime bottlenecks. I'm beginning to believe that this may be pretty easy, my current plan is more or less:
1) Hack into OP_CALL and OP_TAILCALL to update some lightweight C structures with timing info in the case that we're running with instrumentation switched on.
2) Maybe reverse engineer Visual Studio's .vsp or .vspx formats so I can turn my raw data into something viewable in a nice GUI.
However, after reading your posts, I'm guessing that you've implemented some instrumentation and profiling hooks that are quite a bit more sophisticated.
Do you have any words of wisdom for someone just starting down this path? (It sounds like, maybe, implementing some sort of sampling-based instrumentation using OP_HALT-like hooks turns out to be faster than hacking a new switch into the core VM?)
There were a couple of other bugs found since that patch was posted as well (mostly quite obscure, but no sense keeping them to myself):
Many thanks for these -- some of those issues looks pretty nasty. I'll ping Seungjae Lee and point him at this thread as well; his debugger appears to be quite widely used, and I'd bet he'd be interested in updating his own VM patch.
