For your sudoku solver, I ran some numbers of my own with client and server JVM. I was running on OS X, but the numbers should translate to most platforms (including Windows).

With the client VM, after warmup, JRuby's run time is around 4.4s.

With the server vM, JRuby's run time improves to around 3.3s. This is a good improvement, but it's not as good as it should be.

There's a few specific aspects of this benchmark that JRuby currently does not optimize well. The nested "upto" blocks cause too much overhead in current JRuby. Blocks are ok, but nested blocks currently cause some issues for the way we optimize Ruby code.

I'll see if I can improve the sudoku benchmark.

I'm also not sure why you even included JRuby in this post, when you only post numbers for JRuby on a sudoku microbenchmark and a startup time benchmark. Perhaps it would be more interesting to see a real application running on JRuby, or perhaps actually show JRuby's IO performance numbers too.

You ran JRuby with Hotspot in client mode. JRuby with the "server" mode is generally much faster, anywhere from 2-3x for CPU-intensive code.

Your JRuby numbers are invalid :)

Yes, unfortunately because Ruby 1.9 includes a broken "gem_prelude.rb" it loads on every startup, we needed to do something similar. To avoid the brokenness, we simply require 'rubygems', which while faster than in previous versions does incur a startup hit. There are also additional native core classes like Complex and Rational that need to be set up. We hope to make more startup-time improvements before final.

Fibers are supported, but be careful: they must spin up a native thread per-fiber, so they're much heavier than under Ruby 1.9.

Continuations are supported only as well as in previous versions of JRuby (that is, not well...the JVM does not support continuations).

Rubinius has done a great job blazing a trail with regards to native libraries and native extensions, and we're very happy we've been able to support the same FFI and C extension APIs in JRuby. That makes Brian's comments about "Neighborly C extensions" even more important, since JRuby suffers from the same limitations that Rubinius does when it comes to writing C extensions to MRI's API. RHASH and RSTRING->ptr are just the tip of the iceberg.

Do not expect to have access to class method tables (we both implement them differently).

Do not try to find the various MRI runtime structures (like the AST, frames, or scope objects)...we have completely different execution models.

Do not expect C extension code to run concurrently (on JRuby now or on Rubinius when it supports concurrent execution). Because of the global nature of many C extensions' state, we both must ensure only one thread hits C code at a time.

And above all know that because JRuby and Rubinius must isolate C code from the locations of Ruby objects in memory, C extensions with very fine-grained APIs (e.g. every method on every class does a call-out to C) are going to perform *much* worse on JRuby and Rubinius due to the extra copying and indirection required. Design your APIs well and with these limitations very much in mind.

(I would also be lying if I said JRuby's C extension support were the recommended path forward. It will work well as a stopgap measure, but the ultimate solution will usually be to port to Java or find an equivalent Java library to use that doesn't suffer from performance and concurrency penalties.)

That said, we still want C extensions to work as well as possible just like the Rubinius guys, and we'll stand with them to educate people (and to work with CRuby's core team!) on how to write fast, reliable extensions.

(And of course the remaining points Brian makes about good OO design apply to any environment...I wholeheartedly agree!)

I thought I'd also mention that three at least JRuby core developers (Tom Enebo, Nick Sieger, and I) will be at JRubyConf 2010 to answer your questions and help you with any JRuby-related issues you might have. This is your chance to meet up with us and other JRubyists, and we're looking forward to seeing you there! :)

Nice post, and it seems like a good use of JRuby to me. Pretty cool way to mask the fact that you have this "big ugly thing" over on Windows that stubbornly refuses to run anywhere else.

Have you considered using JRuby for the other end of your app too? It might be possible to do everything JRuby-based, if that would make sense for your application.

So far, I have not. The timezone data appears to be normal but perhaps a bit wasteful, since most applications will never need all that timezone information. The right fix would probably be to lazy load such data, but I'm not yet familiar enough with the library to do that. Exercise for the reader?

Part two will go into another tool for browsing JRuby heap dumps: The Eclipse Memory Analysis Tool.

It's there, at the very bottom in tiny gray print:

"This article was originally published on Charles Nutter’s blog Headius."

I agree it could be made more prominent :)

OQL can query against instance variables, but it's a bit more roundabout. You need to look first at the object's metaclass, which holds an array of instance variable names. The index of the name is the index into an instance variable table on the object itself. For that sort of thing the current tools are a bit "raw" since the Ruby object structure doesn't map directly to Java, but I hope to fix that (by having at least the "known" instance variables generated into regular Java fields when the "real" Java class is created).