

Descent into Darkness: Understanding your system’s ABI is the only way out - ice799
http://timetobleed.com/descent-into-darkness-understanding-your-systems-binary-interface-is-the-only-way-out/

======
Estragon
TL;DR: Slides from a talk describing how to rewrite the Ruby VM in memory
_while it is running_ in order to collect garbage which Ruby is not clever
enough to collect for itself.

Yes, it sounds masochistic to me, too.

~~~
crux_
Nitpicky correction: It doesn't do any garbage collection; it helps you figure
out where you are leaking references.

------
jey
a) Clever. b) Cringe!

I really like Ruby as a language, but the ecosystem is just not up to snuff,
which is why I've gone back to Python. The docs are complete, the standard
implementation is rock solid and only getting better (cf. unladen-swallow),
and I can interface with C stuff easily (cf. Cython). I'm looking forward to
Ruby maturing.

~~~
tptacek
We push Ruby harder than most people ever push Python and I'm just not seeing
the maturity problems you're alluding to. Maybe you could be more specific?
We've got Ruby talking to chipsets, controlling WinDBG, debugging processes on
Win32, Linux, and OSX, controlling DynamoRIO, running god knows how many
different network protocols, calling into Java, routing raw packets with pcap,
debugging J2EE container VMs, and fuzzing libraries written in C and C++.

(By the way, don't waste time with the Python C interface. Use ctypes. Ruby
calls it Ruby/DL or "ffi".)

~~~
gte910h
Don't waste time with ctypes, use weave or sip or swig :OP

~~~
tptacek
I'd rather eat a bug than ever use SWIG again.

~~~
mst
Seconded. And I'm perfectly comfortable using XS to bolt perl and C together.

That may be a function of my having spent enough times in the guts of the perl
VM to already know exactly what I want and not want anything getting in the
way while I'm implementing that, mind.

------
erydo
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.

~~~
tbrownaw
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. :)

~~~
ice799
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.

~~~
jrockway
"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 ;)

------
mrcharles
This stuff is just epic. I love it even though I'll never have a use for it,
and don't see the point in the first place.

God bless crazy hackers, I live vicariously through your insanity.

~~~
techiferous
It's actually quite useful. Memory is often the scarce resource on web
servers. This helps you troubleshoot Ruby memory leaks, which could end up
saving you a lot of money in server costs (and speed up the performance of
your app).

