Discussion of JVM performance from JRuby/Clojure creators

My current project is JRuby on Rails, so I wanted to inject my few cents, and also to ask what your long-term experiences with the platform were.

Rake tasks are definitely slow; you have to wait a few seconds for them to complete, which overall sucks. A lot. If anything, this is the one thing that has pushed me to thinking about using MRI again. Nailgun is supposed to help a lot here, and since JRuby 1.4.0 was recently released, I'll be giving NG a go and seeing what the improvement is for common rake tasks.

RAM hasn't been a big problem for me. The JVM does use more RAM than MRI, but it also seems to do a better job of managing it. I've never had an out-of-memory error, and the nastiest benchmarks I could throw against my code (a few hours' worth of solid requests) don't jack the JVM above around 200M of RAM, and that's with an embedded Solr server for indexing/searching. BUT... we haven't done a fully public beta yet, just the 'friends and family' version. So I could be talking out of the wrong orifice here.

You get real threading, which makes setting up a job scheduler a lot easier, and lets you run a multithreaded Rails server.

The performance is quite good when compared to the 1.8.7 MRI.

Accessing Java classes isn't as nice as Closure/Groovy, but that's to be expected. Closure and Groovy were designed from the ground up to use Java classes as their foundation, and Ruby... wasn't. Even so, JRuby does a decent job of autoboxing most of the time with strings and arrays, and I've had only a few speedbumps when using Java classes in JRuby.

Loading JARs seems to work fine with 'require' for me; what problems have you run into?

What is the long-term memory use for your application like; e.g., does it grow hugely over time, or remain relatively stable after the JVM warmup?

What JVM/JRuby are you using?

Other than startup slowness, what other issues have been problems for you?

As a counterpoint, not every Ruby app is a Rails app. I've been using JRuby more and more lately for various text analysis projects. Calculating the mutual information over a huge set of tokens, for instance, was roughly 10 times faster in JRuby... And of course didn't suffer from the Unicode issues I was running into with Ruby (1.8). Regardless of whether or not it's suitable for Rails, it's absolutely suitable for other projects.

When I worked on a sizable JRuby/Rails codebase, our team had a hybrid approach: ephemeral jobs (rake tasks, migrations, autospec) all ran under MRI, while long-lived processes (app servers, CI/acceptance test runs) ran in JRuby. That gave us the best of both worlds: quick startup in cases where total runtime was an issue, and better throughput (and more predictable memory usage) for CPU-heavy workloads.

In my experience, MRI/REE fits into smaller RAM footprints only in cases where either you start up and shut down runtimes relatively regularly, or you can monitor for runaway leaks and terminate bloated processes.

I do agree that switching to a different runtime just to get access to a few libraries is probably the wrong approach, however. The big wins in using JRuby are, to me, twofold: a nice performance boost for general application code, and the availability of robust, battle-tested application servers. Mongrel, Unicorn, and Passenger are fine if you're willing to live on the edge, but if you have a more conservative ops team, or simply don't want to both with rolling your own monitoring and deployment stack, being able to drop a Rails app onto Tomcat or Glassfish as a single WAR file is pretty damn nice.

are you using the 32 bit or 64 bit jvm? The 64 bit doesn't have the client mode so it's going to be a lot slower at startup.

i hear you about the ram. i routinely get Jruby to crash with 'out of memory' errors even with min and max heap set to huge sizes, when YARV doesn't break a sweat.

Edit: I'll add that I'm not talking about rails, I use ruby for heavy data crunching. For general use jruby is great and I love that threads truly run in parallel.

> Running unit tests has been so painful that we hacked Rails to run tests via Web interface.

If that's because of the warm-up problem, Groovy is much better since it doesn't start a new JVM for each test.

> Moreover, accessing Java classes from JRuby isn't nearly as smooth as using something like Closure. Ruby strings aren't Java strings and it applies to arrays, hash tables, everything.

With Groovy, it's about as seamless as you're going to get. That was very much a design goal of Groovy.

The down side is, if you already know Rails, you have to learn half a language (Groovy borrows a lot from Ruby, so you only have to learn the deltas.) And of course you can't use Ruby packages. But you do get all Java libraries for free.