CC: ruby-core for feedback:

> So after initial interest, we're uncertain about using a mark-table GC
> instead of marking each memory segment in the segment itself?  Why?
> The value of REE would shrink if it's benefit depended on whether the user
> cared about releasing memory allocations all the way back to the OS.  And I
> suppose the Ruby makefile itself could just have a tcmalloc flag.
> Speaking of the Ruby makefile, I think 100% of US Ruby users would rather
> NOT include the nkf.so (Kanji) lib in their build.  It's 30% of
> the interpreter's footprint!  But nobody ever picked up on my post:
> http://izumi.plan99.net/blog/index.php/2008/01/14/making-ruby%E2%80%99s-garbage-collector-copy-on-write-friendly-part-7/
> And I'd be surprised if there wasn't a smaller lib for YAML parsing than
> 'syck' - which is another 30%...
> What do you think?

How can you discover this percentage?
I too am somewhat miffed at ruby's rather large memory usage [though
mostly in rails...yikes!]

Fascinating.  There was another fella that mentioned wanting to slim
down 1.9 somewhat, so you may do well with posting your observations
to ruby-core and see what they think.

You could also them if they'd be interested in a patch allowing for a
[user specifiable] link to tcmalloc instead of gcc's, I suppose.  Or
ask Hongli to do so :)
The drawback of tcmalloc being still that some might not want to use
it since it never releases memory back to the original system and is
"hard" to link right in 64-bit and OS X.


For some reason Hongli submitted a patch that was [probably, for all
intents and purposes] fine speed-wise, in March of this year [I
think].  Then nobody benchmarked it and it basically was forgotten
about.

Now recently there's a "new" cow friendly patch for 1.9 which is "all
or nothing" currently--no toggle on /off switch, like Hongli's had.

The new patch is still slightly slower [and what percentage of ruby
users ever will use fork() in their scripts?  like 0.5%?], and would
use more RAM for the mark-table.

So it's still a speed issue, though possibly that could be overcome,
if someone were to do it :)  Hmm.  In combination with my
multi-process patch from earlier it would definitely be faster than
normal GC :)

Thanks!
-=R