Comments on: Making Ruby’s garbage collector copy-on-write friendly, part 3

By: Why mod_rails is a really good thing for light-duty Ruby on Rails at Pervasive Code

Mon, 14 Apr 2008 20:30:28 +0000

[…] interesting alternative was some experimental hacking to MRI’s garbage collector by Hongli Lai, to store its working data separately from the objects being examined, so that preloaded Ruby code […]

By: 赖洪礼的 blog » Making Ruby’s garbage collector copy-on-write friendly, part 4

赖洪礼的 blog » Making Ruby’s garbage collector copy-on-write friendly, part 4 — Sat, 13 Oct 2007 20:54:42 +0000

[…] previous attempt implements the marking table with a set structure. In part 3, Dan42 said that I could use a bit field instead. The idea did occur to me in the past, but I […]

By: Hongli

Hongli — Fri, 12 Oct 2007 09:12:07 +0000

Dan42, you’re brilliant. Why haven’t I thought of that. I might be able to put a marker bit field in each Ruby heap and use that as mark table instead. I’ll give it a try when I have time.

By: Dan42

Dan42 — Fri, 12 Oct 2007 03:47:02 +0000

This is all very very interesting. I’m glad I’m not the only one with concerns about ruby’s GC memory performance (or lack thereof). Fortunately, this had been fixed in ruby 1.9. Unfortunately, I’m not sure rails will ever be compatible with 1.9.

Have you considered using a large bitfield instead of a hash? If you have 3 chunks with n1, n2 and n3 objects you could allocate a (n1+n2+n3)-bit field (only 1 memory allocation!) and use that instead of FL_MARK. I don’t think you can beat 1 bit per object.

By: Hongli

Hongli — Thu, 11 Oct 2007 09:26:45 +0000

I haven’t worked on this since July. I also tried to do the marking in a separate process in order not to touch the heap of the parent process, but performance degraded literally by a thousand fold (probably because of context switch overhead) so I gave up.

I’ve tested mongrel_light_cluster + patched Ruby on a small website, and so far it seems to work well (i.e. no stability problems). I’ve seen mongrel_light_cluster fail on Mephisto, and I later found out that it’s because mongrel_light_cluster doesn’t properly support RoR’s config.load_paths. That’s something I should fix some day.

Ben: your approach is very interesting. Your code doesn’t seem to be compatible with mine, but perhaps I could use some of your ideas.

By: JJV

JJV — Thu, 11 Oct 2007 02:22:18 +0000

Hi,

I’ve been looking for a way to reduce mongrel memory usage and came across your blog.

Would like to know your current status on this project and if you know of anyone that has tried implementing your mongrel_light_cluster and how that has worked for them.

Thanks.

By: Ben Osheroff

Ben Osheroff — Wed, 10 Oct 2007 01:31:04 +0000

Hi, ruby loves to play around with objects on the heap. In my work with getting copy-on-write efficiency, I found that I needed to
sort the nodes into two groups: those likely to tinkered with later by ruby, and those not). So, I created two types of heaps: immutable and mutable. immutable heaps are filled by ruby until you fork(), at which point ruby tries not to touch them, so as not to dirty the vm page.

This patch also has a concept of a separate mark table along with immutable/mutable heaps. It’s against 1.8.5 (with some other patches applied, I forget quite what), but it should give you the general idea.

http://www.gimbo.net/changeset_r7142.diff

By: Kevin

Kevin — Fri, 05 Oct 2007 17:12:25 +0000

Any more progress on this? I love the work you’re doing. The fact that the ruby core team hasn’t looked at how it behaves under fork() really pisses me off. There are lots of rails processes out there that would run much faster on GBs less of ram if this wasted copy-on-writing was fixed…