Comments on: Fixing Threads in Ruby 1.8: A 2-10x performance boost

By: Ruby Enterprise Edition 1.8.7-2010.02 released – Phusion Corporate Blog

Ruby Enterprise Edition 1.8.7-2010.02 released – Phusion Corporate Blog — Mon, 07 Jun 2010 12:32:16 +0000

[...] zero-copy context switching patch, included as an experimental [...]

By: Ruby Enterprise Edition 1.8.7-2010.01 released « Phusion Corporate Blog

Ruby Enterprise Edition 1.8.7-2010.01 released « Phusion Corporate Blog — Wed, 20 Jan 2010 22:07:41 +0000

[...] zero-copy context switching patch, included as an experimental [...]

By: links for 2009-12-16 « Bloggitation

links for 2009-12-16 « Bloggitation — Thu, 17 Dec 2009 06:09:08 +0000

[...] Fixing Threads in Ruby 1.8: A 2-10x performance boost at time to bleed by Joe Damato (tags: ruby tuning programming) [...]

By: State of Ruby VMs: Ruby Renaissance - igvita.com

State of Ruby VMs: Ruby Renaissance - igvita.com — Fri, 20 Nov 2009 22:04:58 +0000

[...] of MRI Ruby. Combination of MBARI patches, improvements in thread and scheduling overhead by Joe Damato and Aman Gupta, a copy-on-write (COW) fork model, and a tunable GC all contribute to a measurable difference in [...]

By: Ruby Enterprise Edition 1.8.7-20090928 released « Phusion Corporate Blog

Ruby Enterprise Edition 1.8.7-20090928 released « Phusion Corporate Blog — Tue, 29 Sep 2009 11:34:31 +0000

[...] Damato and Aman Gupta have created a patch which implements zero-copy context switching in Ruby’s threading system. In Ruby 1.8, whenever Ruby switches context to another thread, it [...]

By: Traveller_Adventure

Traveller_Adventure — Sun, 02 Aug 2009 10:36:19 +0000

This is quite impressive, I am pleased to read this post, keep posts like this coming, you totally rock!
Cheers,
Blog Review

By: Dominic Mitchell

Dominic Mitchell — Wed, 20 May 2009 23:24:24 +0000

Hmmm, reminds me of the awful bourne shell memory allocation. That used to allocate more memory by catching seg faults.

By: ice799

ice799 — Tue, 19 May 2009 04:10:28 +0000

Hi Wheels.

Yeah, we had that idea, but we didn't implement it. Shouldn't be too hard, we may experiment with it and see what happens.

Thanks for reading.

By: Scott Wheeler

Scott Wheeler — Tue, 19 May 2009 03:44:09 +0000

Why couldn't you increase the stack size in the signal handler? (It'd be expensive with the massive memcpy that would ensue, but presumably better than a crash.)

By: ice799

ice799 — Tue, 19 May 2009 01:34:33 +0000

mmap() is pretty crucial for this implementation -- I need to be able to specify permissions bits for the region of virtual memory which will serve as the stack. If I can't do that, I can't be sure the stack is actually in a sane, usable state.

Anyway, the inline assembly is tying this implementation to specific platforms very much more so than the mmap() usage, but that is fine by me. The only platforms that this implementation supports are platforms which also expose mmap().

Thanks for reading.