Ruby 2.1 Garbage Collection to Address Criticism on Large Scale Deployments

http://www.infoq.com/news/2013/09/ruby-2-1-gc-revamp

by DanielRibeiro • 13 years ago

66 62 13 years ago

exDM69• 13 years ago

You should go and read the Ruby Garbage Collector implementation. It's very straightforward to read, the code is simple but reveals why it's so slow. I won't say anything bad about it but it's not a stellar piece of software engineering.

The good thing is that there's plenty of room for improvement.

ioquatix2• 13 years ago

What surprises me is that there are a lot of companies using Ruby. Why don't they put their money where their mouth is? Hire a team of sufficiently skilled developers and pay them to improve the GC implementation. It isn't rocket science :)

mikekersehy• 13 years ago

There's only so many GC engineers in the world, and the majority work in academia, industrial research labs and places like the Oracle VM team. So some web-app company isn't likely to hire one. Also they aren't interested in making some toy GC for a language they don't use.

rapind• 13 years ago

I wonder if rocket scientists say "It's not like we're building a garbage collector".

cheald• 13 years ago

Throwing another few boxes into your web app is significantly cheaper than hiring a GC engineer to rewrite the implementation.

BruceM• 13 years ago

It is too bad they aren't looking at the very nice MPS: http://www.ravenbrook.com/project/mps

mje__• 13 years ago

Is Github still running Ruby 1.8? vmg mentioned at last year's Rubyfuza they had "one of the largest 1.8 deployments in the world".

imbriaco• 13 years ago

Nope, we're on 1.9. We were briefly on 2.0 (last week) but had some minor performance regressions that we need to understand before we go back.

rustc• 13 years ago

Are the videos of the talks available? or more details about the implementation of the new architecture?

lucaspiller• 13 years ago

They will be eventually on http://www.baruco.org/. The conference has only just finished.

steveklabnik3• 13 years ago

https://news.ycombinator.com/item?id=6393413

gary4gar2• 13 years ago

Sad fact is MRI even with no matter how much effort we put in would never would be able to match GCs of battle tested VM like JVM.

so I am wondering, it makes sense to stop designing a VM & just focus on language. Perhaps, something like Truffle can be used to do the optimizations for you. Ruby on truffle is already 4-5x faster than MRI. And the ruby implementation was done by an intern in just 6months. All because power of JVM.

        https://twitter.com/headius/status/362616159897534465
        http://www.oracle.com/technetwork/java/jvmls2013wimmer-2014084.pdf

Something to keep in mind.

Argorak5• 13 years ago

Most Ruby implementations started with awesome numbers in a ridiculous short time. Remember the time when MacRuby was 6 times as fast as MRI? Those times are over after they implemented Ruby proper and ran real world programs.

gary4gar2• 13 years ago

Curious to know what are thing in "ruby proper" that make it slow?

coldtea7• 13 years ago

Haven't seem them getting slower in later stages, and surely not THAT slower. Any citations?

Their main problem is that the project got mostly abandoned in favor of the paid-for RubyMotion (which uses AOT compilation).

That said, Lua and JS are as dynamic and Ruby and both are plenty faster.

And PyPy is plenty faster than Python, despite being 100% compatible now.

riffraff• 13 years ago

I wanted to find the reference but I failed.

Anyway, I just wanted to counter that IIRC mike pall of luajit fame has stated that in his opinion a VM/JIT laser focused on a single language's semantics is much easier and in the end more effective than using a general purpose one.

Alas, I can't find the reference, but the luajit example stands on his own. Whether designing your own VM is a better use of money&time is largely a trade off of what your targets are. E.g. HotSpot could have been a great target unless you are interested in fast startups, or whatever.

vidarh7• 13 years ago

The numbers for Ruby on Truffle are meaningless until people have had a chance to hit it hard with all the particular oddities of Ruby. Consider their 6 months was to hit 45% of RubySpec. You can reach 45% of RubySpec fairly easily if you go for the softest targets (I'm not saying that's what they've done - I haven't checked).

[EDIT: I see they're doing some interesting things that certainly ought to beat MRI. If I understand it correctly it seems like they are somehow collapsing type checks for multiple operations. Of course the devil is in the details - if they are trying to defer type or method checks, and throw away results if the checks fails (which should be rare) that will only be safe if modifications that does happen does not introduce or remove side effects that can't be "rolled back", but I might be misunderstanding their presentation]

The problem is the multitude of bizarre things that are legal Ruby. Like people doing eval("class Fixnum; def + other; 42; end; end;"). Yes, that's legal, and yes that means any integer arithmetic in your application is suddenly broken. More importantly it means any optimisations based on your beliefs about what any piece of code is meant to do, while they are most likely right, can turn out to be horribly wrong and so are problematic for a VM or compiler, without substantial amount of logic to be able to detect or bail out from optimised code to safe fallbacks. Doing so without slowing down the code when your guesses are right is hard because of how many ways there are of changing the behaviour of code in Ruby.

Unless your compiler understands eval() and it is possible for it to reason about the contents of the eval string, it can make pretty much zero guarantees about the state of the world after an eval() call, and so it can make pretty much zero guarantees about the state of the world after any method call that could reach such an eval() call.

Admittedly, that's a stupid thing to do, but it's legal in Ruby, and while the above example is extreme, you do find a lot of use that is roughly equivalent. E.g. autoload creates as much lack of predictability as eval. So does a 'require' or 'load' that might get triggered later in execution, for example.

The reason those are important is that it makes a massive amount of optimisations far harder: You can't blindly cache method pointers, for example, because any method call potentially invalidates them. You can't even cache class pointers, because they can change: You can return from a method call and suddenly an object has an eigenclass. You can't inline functions without guarding them somehow to fall back to the full method call when it turns out some idiot did redefine Fixnum#+. You can't assume seemingly "safe" stuff like Fixnum#+(some other Fixnum) will even return an object of the type you assume, for the same reason - someone might decide to implement a DSL that redefines it.

Frankly, it'd be fantastic to start deprecating some of the more obnoxious things like these, and weeding out the few uses of them, but as it stands today, a fast Ruby subset is "easy". A fast complete Ruby implementation is an entirely different beast. A fast incomplete Ruby implementation that refuses to support some of the most noxious corner cases would still be extremely useful for a lot of people, though.

(in the interest of disclosure since I'm talking about another Ruby implementation: I'm writing a series on my own slow process of writing a Ruby compiler, though my goals are very different - mostly focused on writing about the process)

coldtea7• 13 years ago

Unless your compiler understands eval() and it is possible for it to reason about the contents of the eval string, it can make pretty much zero guarantees about the state of the world after an eval() call, and so it can make pretty much zero guarantees about the state of the world after any method call that could reach such an eval() call.

That's also true for Javascript, but it hasn't stopped three separate teams (Mozilla, Apple, Google) making it crazy faster than Ruby.

chrisseaton2• 13 years ago

I'm the author of Ruby on Truffle.

I'll talk you through exactly how we solve the problem of redefining Fixnum, as one example of how we've tackled these problems.

Whenever you use Fixnum#+ in one of your methods, we lookup what that method is and cache the method so we can call it quickly next time. We actually never again check that this cache is still valid. The trick is that we sort of do the opposite - any time you do something that could invalidate that cache, we find the installed machine code that uses it, and delete it. If the machine code is still running somewhere on some stack for some thread or fibre, we jump from the machine code into an interpreted version which looks up the method again and carries on.

So Kernel#eval makes no difference - if something that you eval ruins your later cached method calls in the same method, that's not a problem because if you're still running the same machine code, then you can't have redefined Fixnum#+. If you had redefined it, you'd be back in the interpreter getting ready to compile again with new caches.

I'll also just point out that running RubySpec means we are successfully running something like 5000 lines of off-the-shelf unmodified systems code, just for the harness before we even get to the tests.

Our theory is that we can make Ruby very fast, without having to forgo any of your favourite random dynamic monkey-patching features.

Watch the video: http://medianetwork.oracle.com/video/player/2623645003001

Join us on the mailing list: http://mail.openjdk.java.net/mailman/listinfo/graal-dev

coldtea7• 13 years ago

Sad fact is MRI even with no matter how much effort we put in would never would be able to match GCs of battle tested VM like JVM.

Nothing imposissible about it happening though. Just money and time.

trailfox• 13 years ago

Ruby and Java were both released in 1995. It's now 18 years later and MRI can't keep up with a 1998 JDK. Could be a long wait...

sluukkonen• 13 years ago

For anyone interested in how it will be implemented, see ko1's presentation slides from Euruko 2013.

http://euruko2013.org/speakers/presentations/toward_more_eff...

Ruby 2.1 Garbage Collection to Address Criticism on Large Scale Deployments

Related Stories