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

By: Wladimir Mutel

Wladimir Mutel — Sat, 30 May 2009 11:13:10 +0000

Had you looked at this ? – http://judy.sourceforge.net/
It’s modern and fast associative array implementation that I think could be useful for REE.

By: roger

roger — Thu, 16 Oct 2008 06:28:07 +0000

Re: speed drop when copy_on_write is turned on. I was thining one way to overcome this would be [hear me out]

Require that heaps be aligned on certain boundaries, like say 2K boundaries [1]. Then for every entry within the heap that is located at exactly a multiple of 2K, have it not belong to the freelist, nor ever be used as a ruby object, but instead be a pointer back to the root of the heap. Thus locating the heap on which an object resides [to locate the mark table for that heap] is able to be looked up in constant time — something like *(object_address & (~2K))
Also doesn’t add much memory, at all, though it does add some complexity.
I could code it up if you’d like. Or does it already do this?
Thanks!
-=R

[xmalloc does this?]

By: Hongli

Hongli — Wed, 20 Aug 2008 07:31:36 +0000

Yes I’ve tried jemalloc for a short while. I didn’t write down the results but I noticed that tcmalloc is more efficient when it comes to performance and copy-on-write friendliness.

By: Phil Murray

Phil Murray — Wed, 20 Aug 2008 01:06:23 +0000

Have you done any comparisons of tcmalloc with jemalloc? jemalloc is FreeBSDs new malloc implementation, that the Mozilla project have also started using for their builds of Firefox etc.

By: Kent Sibilev

Kent Sibilev — Mon, 18 Aug 2008 19:08:03 +0000

Thank you for your great work! I’ve switched all my production sites to Passeger/REE which resulted in a considerable performance boost.

By: J. Ryan Sobol

J. Ryan Sobol — Mon, 18 Aug 2008 06:07:28 +0000

Thank you for your hard work! More importantly, thank you for contributing back to the community!

The transparency of Phusion *will* most certainly aid in early adoption. I only hope the branch in the trunk wraps tightly around the base.

By: Hongli

Hongli — Mon, 18 Aug 2008 05:38:37 +0000

I personally have no plans to implement Python support because I don’t write web applications in Python, but I would welcome any contributions for improving Python support.

Please feel free to share your ideas, I’d very much like to hear them. Especially if they’re architecturally disruptive — that just means that you must be up to something.

By: Brian Smith

Brian Smith — Mon, 18 Aug 2008 01:06:52 +0000

What are your plans regarding the Python support for Phusion Passenger? For a long time I’ve been interested in doing something very similar for Python to what you are doing in Ruby EE/Passenger. It looks like your Python support is at the “it works” stage but it doesn’t seem to be optimized like the Ruby support.

Also, how do you feel about derivative works? I have some ideas for architectural changes to Passenger to improve IPC performance that are very disruptive. I’d like to share those changes publically even if you guys don’t want to merge them.

By: Hongli

Hongli — Sun, 17 Aug 2008 20:09:08 +0000

We’ve had no luck with tcmalloc on 64-bit platforms so far, so the installer doesn’t install tcmalloc on such platforms.

By: Stephen Sykes

Stephen Sykes — Sun, 17 Aug 2008 19:00:28 +0000

Hi! Interesting about tcmalloc being such a benefit. But I am on x86-64 and you say in the REE FAQ that the tcmalloc does not work on 64bit platforms.
However, I notice that the current docs for tcmalloc say that tcmalloc itself works fine, it’s just some of the other parts of the google perftools that can cause problems/deadlocks. Therefore is it still the case that there is no performance benefit for 64bit?