Comments on: Making Ruby’s garbage collector copy-on-write friendly, part 6 (final?)

By: trickyco.de » Blog Archive » hacking on ruby’s garbage collector

trickyco.de » Blog Archive » hacking on ruby’s garbage collector — Wed, 06 May 2009 08:10:03 +0000

[...] (this guy gets the credit on this idea) Because we do scanning copy on write semantics are blown. you do a fork, and as soon as GC runs, your whole heap is resident and private memory. [...]

By: Crystal

Crystal — Thu, 17 Apr 2008 00:35:47 +0000

Wow these are very big savings, thanks again.

By: Hongli

Hongli — Thu, 20 Mar 2008 10:07:04 +0000

No, the memory savings are caused by copy-on-write semantics.

By: roger

roger — Thu, 20 Mar 2008 05:01:47 +0000

I assume most of the memory-savings is because of using fixed-length “heap blocks”?

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

赖洪礼的 blog » Making Ruby’s garbage collector copy-on-write friendly, part 7 — Mon, 14 Jan 2008 12:50:14 +0000

[...] turns out that part 6 was not final. I’ve been working on the garbage collector again. These are the [...]

By: lloyd hilaiel

lloyd hilaiel — Fri, 26 Oct 2007 20:30:23 +0000

hi.

I’m embarked on a similar mission. make ruby use less memory without going too much slower. I’ve got a set of very simple test cases, and ran then on 1.8.6 after applying your patch. it’s interesting to note that you’ve got about a 8% performance hit in combination with the 33% memory usage gain according to my toy tests:

vanilla 1.8.6:
running cases/growarray.rb
time 1.355438
running cases/plist.rb
time 3.693722
running cases/shrinkarray.rb
time 1.351735

cowfriendly 1.8.6:
running cases/growarray.rb
time 1.485687
running cases/plist.rb
time 4.006008
running cases/shrinkarray.rb
time 1.48557

(/ 3.693722 4.006008)
(/ 1.351735 1.48557)

~8% performance penalty.

I’d imagine for a lot of folks this is a tradeoff they’re willing to make (8% is a lot better than swapping and paging , but thought it might be interesting to you anyways.

By: Roger Pack

Roger Pack — Mon, 22 Oct 2007 21:11:59 +0000

You should submit this to the mongrel guys

By: Jeremy

Jeremy — Mon, 15 Oct 2007 17:03:35 +0000

Actually, upon further review, it doesn’t. They don’t call start. I had a check inside the module, which was outputting, but start never gets called. I’ll just run with the standard mongrel for now, and change up “swiftiply_mongrel_rails” to use your stuff instead later.

By: Jeremy

Jeremy — Mon, 15 Oct 2007 16:51:34 +0000

Already did that. – It is.

By: Hongli

Hongli — Mon, 15 Oct 2007 16:27:57 +0000

I'm not sure whether mongrel_light_cluster is compatible with swiftiply_mongrel_rails. You can check whether mongrel_light_cluster is actually active by checking this:

module Cluster
  module ExecBase
    if @@light_cluster_initialized
        puts "mongrel_light_cluster is active"
    end
  end
end