The way presented has very high cost of initial creation, and almost negligible setup overhead per user ('user' being a programmer who wants memory use info).
Patching and recompiling has moderate-low cost of initial creation, but also moderate-low setup overhead per user.
Plus, some of us think this kind of thing is just plain fun. :)
I built this because I like working on this sort of thing and because it lowers the bar for everyone else who doesn't know how to or want to rebuild their binaries.
Also, depends a lot on your infrastructure. Sometimes it's easier to distribute and maintain patched Rubies, and sometimes it's easier to just require a ruby gem. The gem is designed and built in such a way that it should be resistant to most changes made to the Ruby VM.
"Click here to download a version of the patched Ruby for OS X". That's as easy, for the end-user, as rewriting the executable on the fly. And it's probably easier for you guys too ;)
I'd completely missed the reusability aspect of things; I guess because the tight coupling to specific addresses would mean redoing a lot of the work for different builds. But once you figure it out, it looks like it could be trivial to replicate for future minor revisions.
And I agree, it's fun stuff! That kind of hacking really makes me smile. I was just curious about the pragmatic motivations.
Sorry, I didn't mean to imply that you had hardcoded the addresses, only that you'll have to go through the process of finding the addresses anew for each build. Not an insurmountable problem (as you've shown), but making it slightly harder to automate.
However, I admit to having had time to only read through it casually, so please take any incorrect statements solely as misunderstanding on my part.
His point was that he was lazy, and wanted to be able to memtrace his production apps using the distro-provided rubies. Not recompiling was the whole point of the exercise.
Comments
Why not just add tracing code to the source and recompile? I don't immediately see an advantage to this kind of hot-patching in this case.
The way presented has very high cost of initial creation, and almost negligible setup overhead per user ('user' being a programmer who wants memory use info).
Patching and recompiling has moderate-low cost of initial creation, but also moderate-low setup overhead per user.
Plus, some of us think this kind of thing is just plain fun. :)
This.
I built this because I like working on this sort of thing and because it lowers the bar for everyone else who doesn't know how to or want to rebuild their binaries.
Also, depends a lot on your infrastructure. Sometimes it's easier to distribute and maintain patched Rubies, and sometimes it's easier to just require a ruby gem. The gem is designed and built in such a way that it should be resistant to most changes made to the Ruby VM.
"Click here to download a version of the patched Ruby for OS X". That's as easy, for the end-user, as rewriting the executable on the fly. And it's probably easier for you guys too ;)
I'd completely missed the reusability aspect of things; I guess because the tight coupling to specific addresses would mean redoing a lot of the work for different builds. But once you figure it out, it looks like it could be trivial to replicate for future minor revisions.
And I agree, it's fun stuff! That kind of hacking really makes me smile. I was just curious about the pragmatic motivations.
I didn't hardcode any addresses. That's why it works on so many different Ruby builds.
Sorry, I didn't mean to imply that you had hardcoded the addresses, only that you'll have to go through the process of finding the addresses anew for each build. Not an insurmountable problem (as you've shown), but making it slightly harder to automate.
However, I admit to having had time to only read through it casually, so please take any incorrect statements solely as misunderstanding on my part.
His point was that he was lazy, and wanted to be able to memtrace his production apps using the distro-provided rubies. Not recompiling was the whole point of the exercise.
I understood that not recompiling was the point; I was wondering why it was a valid point.
"Because you want to do it to a running production app" seems far-fetched to me -- not saying that it is, I had just discounted that reasoning.
tbrownaw's point of 'high initial cost, low marginal cost' makes a good amount of sense, though.