Rewrite your Ruby VM at runtime to hot patch useful features

I love posts like this, but I think the authors would benefit from a close read of the Microsoft Detours paper, which runtime patchers have been cribbing from for the past 5 years or so.<p>The general Detours approach:<p>* Disassemble the first N bytes of a target location<p>* Scoop N bytes worth of opcodes out of the target, and re-host them somewhere heap-allocated<p>* Replace the N bytes with an absolute jump to a heap-allocated trampoline<p>* Bounce to your code<p>* Execute the scooped-up N bytes worth of opcodes<p>* Jump back to the target<p>This approach (what the post calls "caller-side trampolines") works well when your targets are function prologues, and less well when it's an arbitrary bblock.<p>We have an implementation in pure Ruby, complete with a pure-Ruby ia32 assembler (which is one of the most useful little pieces of code I've written) at Timur's Ragweed repository --- google "Ruby ragweed github".

See also: <a href="http://rentzsch.com/mach_override" rel="nofollow">http://rentzsch.com/mach_override</a><p>It used to be used quite comprehensively to add non-Apple-sanctioned functionality to Mac OS X. Hopefully it isn't used much these days.

I'm probably not thinking this through all the way, but wouldn't a memory profiler be more straight-forward, and less dangerous in Smalltalk?<p>I haven't built one myself, but I know that the Seaside framework comes with a built-in memory profiler.<p>Doing intercession of messages to objects in Smalltalk isn't trivial, but it isn't voodoo either. I whipped up a quick method replacement class that swaps out a database 'save' method's behavior for testing. However, I would imagine that trying to replace VM primitive calls would lead to some not-so-nice side effects (maybe... or would it just make the image slower?).<p>I like Ruby, and I like Smalltalk, but I'm liking Smalltalk much better lately because the "turtles all the way down" aspect which makes things like a memory profiler much less "voodoo-y".

I am surprised this works. I was under the impression that more modern implementations write protected the pages that libraries in the initial link are loaded to. There is really no good reason for them to be writable save for extremely strange uses such as in this article.<p>Is this assumption false?

This is a perfect example of "because I can". Never ever do this for real.