Comments on: Latest Ruby on Rails prefork script

By: Nina

Nina — Wed, 21 Jan 2009 15:05:35 +0000

Oh, it’s true, I know!

By: 赖洪礼的 blog » Status report

赖洪礼的 blog » Status report — Fri, 20 Jul 2007 12:25:25 +0000

[...] been a while since I worked on my Ruby on Rails-related projects, saving memory by using copy-on-write and prepared statements support in ActiveRecord. They were on hold for a while since I’ve [...]

By: R.O.

R.O. — Mon, 25 Jun 2007 14:26:50 +0000

Would like a followup to this. This single issue about GC ruining COW semantics. Is there any work on improving to a more intelligent GC?
Thanks.

By: Hongli

Hongli — Tue, 22 May 2007 08:36:51 +0000

I've had more success with this script:

a = []
(1024 * 1024).times do
	a.push(" " * 200)
end
pid = fork do
	while true
		$stdin.readline
		a = nil
		ObjectSpace.garbage_collect
	end
	exit!
end
Process.waitpid(pid)

Memory usage increased a bit, but not as much as I heard it would.

By: Hongli

Hongli — Mon, 14 May 2007 13:01:51 +0000

Is that really so? I have heard of that story but I'm unable to reproduce it. For instance, look at this test script:

a = " " * 1024 * 1024 * 100
b = " " * 1024 * 1024 * 50
pid = fork do
	$stdin.readline
	b = nil
	ObjectSpace.garbage_collect
	$stdin.readline
end
Process.waitpid(pid)

After I press Enter for the first time (thus forcing garbage collection), I do not see my memory usage go up at all.

By: Ezra

Ezra — Mon, 14 May 2007 08:52:13 +0000

The problem with fork and cow memory in ruby is that as soon as ruby’s GC runs in a child process it walks the ObjectSpace touching every object and basically makes the kernel think it needs its own memory space for all objects. So as soon as GC runs in the forked child it needs as much ram as the parent and cow semantics are ruined.