Ruby's bin men: a closer look at the garbage collector #73

wants to merge 1 commit into


None yet

The Garbage Collector: how does it work?
What does it mean when people speak about stop-the-world, mark-and-sweep, generational garbage collectors?
How does ruby fare at collecting its own garbage?
What does it mean when they say 1.9.3's garbage collector has improved?
This talk will explain those concepts, what the impact of garbage collection is on our programs, and what future could be.

I'm sorry, I couldn't resist.

Stupid Joke

Also 👍

niklas commented Mar 20, 2012

I expect a song or prayer at the end containing "and all my references were counted down to zero"

txus commented Mar 20, 2012

GREAT! Thumbs up! Although I won't be able to attend Euruko :'( I'll wait for the videos.

p.d: do you plan to do it for Baruco as well? hehehe. :P

mpapis commented Mar 20, 2012

👍 I would love to see a comparison to JVM GC (is Ruby better at GC ?)

5v3n commented Mar 20, 2012

👍 especially interested in code optimization, e.g. two methods with equal outcome but massive gc

csgui commented Mar 20, 2012

Interesting proposal. +1.

mackuba commented Mar 20, 2012


golov commented Mar 20, 2012


I'd be interested in this talk, provided you make a clear distinction between Ruby and MRI. Ruby garbage collection != MRI garbage collection. For example Rubinius implements a Generational Garbage Collector that is a lot more sophisticated than MRI's simple mark-and-sweep:

paukul commented Mar 20, 2012


@leocassarani that seems clear to me, too. I'll try and avoid sowing any confusion.

tlossen commented Mar 20, 2012


(especially if you would also compare the MRI garbage collector to JRuby / Rubinius)

cabo commented Mar 20, 2012

Maybe add a short segment on and how the useful strategies for this change with different GCs.

headius commented Mar 21, 2012

I'd be happy to help you show graphs, logs, tuning and impl details for the various JVM garbage collectors, which of course JRuby takes advantage of.

nahi commented Mar 21, 2012


@headius, when you show the difference of GC time between JVM and YARV, audience will realize that how YARV's bytecode processing is fast. You'd better let invokedynamic and IR go live first? :)


@headius I think you would be a much better candidate to do this talk :) Yes, all information is more than welcome, I only have a superficial knowledge of what's going on in the JVM,

headius commented Mar 22, 2012

@nahi That would be worth it if it helped encourage more work on speeding up 1.9.3's GC :)

I have noticed a disturbing trend, too...1.9.3 GC is slower than 1.9.2, and 2.0.0dev is slower than that. Things seem to be moving in the wrong direction :(

@elisehuard When you start putting together info for your talk (assuming it is accepted) let me know.

nahi commented Mar 23, 2012


I have noticed a disturbing trend, too...1.9.3 GC is slower than 1.9.2, and 2.0.0dev is slower than that.

Besides 2.0.0dev, 1.9.3 should be "slower" than 1.9.2 from "total GC time" point of view. That's what lazy sweeping, that is for improving GC response time, as you know :) I don't think that "things seem to be moving in the wrong direction" but possible affected users should care about the change. @elisehuard will help you understand by pres.? :)

headius commented Mar 23, 2012

I'll try to dig up the benchmark results, but what I noticed was 1.9.3 and 2.0.0dev took longer to complete object/garbage-heavy benchmarks than previous versions. It was not simply a matter of total CPU time or total GC time, but total end-to-end completion time of a single-threaded benchmark that created a lot of garbage.

nahi commented Mar 23, 2012

Ah, I remembered that you tweeted something about it. @authorNari would be interested in it. I heard that a script that keeps lots of long-live objects may face worse GC throughput time than expected but IIRC your (or @evanphx's?) PoC GC benchmark was different example.

...Sorry for trolling this thread...

headius commented Mar 26, 2012

@nahi The test is in the gc_tests project on my github, and does indeed include a mix of young and old objects. I fear that "lots of long-lived objects may be more common than people realize. Rails, for example, is not small in memory.

If I didn't already: +1 for this talk :-)


ghost commented Mar 26, 2012


DouweM commented Mar 26, 2012


jasiek commented Mar 28, 2012


ayosec commented Mar 29, 2012


driv3r commented Mar 29, 2012


hpdev commented Mar 30, 2012


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment