caller_for_all_threads now in Ruby Enterprise Edition

The awesome guys behind Phusion Passenger just released a new version of Ruby Enterprise Edition, which includes my work on caller_for_all_threads. For people who are not keen on patching and compiling their own Ruby interpreter, this is great news. Now, to be able to dump the stack trace of all the threads in your Ruby application… all you need to do is to install Ruby Enterprise Edition!.

If you are unfamiliar with caller_for_all_threads, it provides a handy way to gain a comprehensive understanding of the state of your Ruby application when it starts to misbehave. I have found it to be a quick and invaluable troubleshooter of tough Ruby on Rails production problems.

As for Ruby Enterprise Edition, if you haven’t evaluated it yet, you should:

In conclusion, I am flattered to have my work incorporated into the core of what constitutes today’s state-of-the-art deployment infrastructure for Ruby web applications (Phusion Passenger + Ruby Enterprise Edition). Hopefully, you will also find my work useful. Please send me your feedback – I’d love to learn about how you use it and your ideas on ways to improve it!


  1. As demonstrated in this test

  2. Especially its mark-and-sweep garbage collection implementation, which is the worst offender. It holds the mark/sweep flag inside the nodes themselves, not in a separate list maintained in parallel. This inlined flag triggers quick memory changes in anything but the very core of the Ruby interpreter. As a consequence almost all the pages that a Ruby child process inherits from its parent change quickly, unnecessarily defeating copy-on-write optimizations.

  3. Copy-On-Write is a transparent optimization technique where a memory copy operation defers the actual copy until a change occurs (either in the original or the copy). Until then, a read-only pointer to the original memory page is provided. Eventually, if/when a process attempts to change the original or the copy, a page protection fault occurs, the O.S. intercepts the page fault and end up allocating physical memory for the copy. So, as long as the copied data is only read and not written too, memory is shared, effectively saving time and physical memory. You typically benefit from copy-on-write optimizations in a transparent manner every time you fork a (Ruby) process.

What Next?

Talk back

Post the first comment to share the love or get a discussion going!

Bookmark it

You can bookmark this document directly or by a simple click to Digg, del.icio.us or Reddit.

Recommend me

If you have enjoyed this article, you might consider recommending me on Working With Rails.

Subscribe to RSS

If you're familiar with RSS, you might want to subscribe to the PH7 RSS feed. You can use one-click subscriptions to our RSS-feed through Bloglines, Google Reader, My Yahoo, Newsgator, Rojo

This work is licensed under a Creative Commons Attribution 2.5 License.

Original web site design by: JFX diz*web.