From: "M. Edward (Ed) Borasky" <znmeb@...>
Date: 2007-11-11T07:32:14+09:00
Subject: Re: enterprise ruby

Roger Pack wrote:

[snip]

> Maybe an optimized GC might not be such a bad idea after all :)

I haven't been following 1.9 closely enough to know what it does about 
garbage collection. But yes, it does look like the MRI GC could stand 
some optimization. Given the trade-offs and use cases, I'd optimize for 
Rails. And I'm guessing that on Linux/GCC, a nice tight stop-and-copy GC 
might well outperform what's there, and a generational GC would be 
better than what's there but not worth the coding effort. I can't help 
you on Windows or MacOS ... the memory management there is a black box 
to me.

Which brings up an interesting question. While it seems more Ruby 
developers work with Macs than with Windows or Linux, where are most of 
the Ruby server applications (Rails and otherwise) deployed? I want to 
guess Linux, but I don't actually know for a fact that is the case.

As a previous email suggested, there are a couple of use cases for a 
garbage collector, only one of them being long-running server 
applications. But if the overwhelming majority of Ruby server 
applications are Rails on Linux, it would surely be worthwhile tuning 
the GC to that. Stop-and-copy integrated with the Linux memory manager 
(assume RHEL 5/CentOS 5 64-bit) sounds like a winner off the top of my head.

Hmmm ... maybe I should dual-boot my workstation with CentOS 5 and fool 
around with this. ;)