Saturday, February 16, 2008

JRuby RC2 Released; What's Next?

Today, Tom got the JRuby 1.1 RC2 release out. It's an astounding collection of performance improvements and compatibility fixes. Here's Tom's JRuby 1.1 RC2 announcement.

Let's recap a little bit:

  • There have been additional performance improvements in RC2 over RC1. Long story short, performance of most trivial numeric benchmarks approaches or exceeds Ruby 1.9, while most others are on par. So in general, we have started using Ruby 1.9 performance as our baseline.
  • Unusual for an RC cycle are the 260 bugs we fixed since RC1. Yes, we're bending the rules of RCs a bit, but if we can fix that many bugs in just over a month, who can really fault us for doing so? Nobody can question that JRuby is more compatible with Ruby 1.8.6 than any other Ruby implementation available.
  • We've also included a number of memory use improvements that should reduce the overall memory usage of a JRuby instance and perhaps more importantly reduce the memory cost of JIT compiled code (so called "Perm Gen" space used by Ruby code that's been compiled to JVM bytecode). In quick measurements, an application running N instance of JRuby used roughly 1/Nth as much perm gen space.
So there's really two big messages that come along with this release. The first is that JRuby is rapidly becoming the Ruby implementation of choice if you want to make a large application as fast and as scalable as possible. The thousands of hours of time we've poured into compatibility, stability, and performance are really paying off. The second message comes from me to you:

If you haven't looked at JRuby, now's the time to do so.

All the raw materials are falling into place. JRuby is ready to be used and abused, and we're ready to take it to the next level for whatever kinds of applications you want to throw at it. And not only are we ready, it's our top priority for JRuby. We want to make JRuby work for you.

And that brings me to the "What's Next" portion of this post. Where do we go from here?

We've got a window for additional improvements and fixes before 1.1 final. That much is certain, and we want to fill that time with everything necessary to make JRuby 1.1 a success. So we need your help...find bugs, file reports, let us know about performance bottlenecks. And if you're able, help us field those reports by fixing issues and contributing patches.

But we also have a unique opportunity here. JRuby offers features not found in any other Ruby implementation, features we've only begun to utilize:

Inside a single JVM process, JRuby can be used to host any number of applications, scaling them to any number of concurrent users.

This one applies equally well to Rails and to other web frameworks rapidly gaining popularity like Merb. And new projects like the GlassFish gem are leading the way to simple, scalable, no-hassle hosting for Ruby web applications. But we're pretty resource-limited on the JRuby project. We've got two full-time committers and a handful of part-timers and after-hours contributors pouring their free time into helping out. For JRuby web app hosting to improve and meet your requirements, we're going to need your use cases, your experience, and your input. We're attempting to build the most scalable, best-performing Ruby web platform with JRuby, but we're doing it in true OSS style. No secrets, no hidden agendas. This is going to be your web platform, or our efforts are wasted. So what should it look like?

The GlassFish gem is the first step. It leverages some of the best features of the Java platform: high-speed asynchronous IO, native threading, built-in management and monitoring, and application namespace isolation (yes, even classloaders have a good side) to make Ruby web applications a push-button affair to deploy and scale. With one command, your app is production-ready. No mongrel packs to manage, no cluster of apps to monitor, and no WAR file relics to slow you down. "glassfish_rails myapp" and you're done; it's true one-step deployment. Unfortunately right now it only supports Rails. We want to make it not only a rock-solid and high-performance Rails server, but also a general-purpose "mod_ruby" for all Ruby web-development purposes. It's the right platform at the right time, and we're ready to take it to the next level. But we need you to try it out and let us know what it needs.

JRuby's performance regularly exceeds Ruby 1.8.6, and in many cases has started to exceed Ruby 1.9.

At this point I'm convinced JRuby will be able to claim the title of "fastest Ruby implementation", for some definition of "Ruby". And if we're not there yet, we will be soon. With most benchmarks meeting or exceeding Ruby 1.8.6 and many approaching or exceeding Ruby 1.9 we're feeling pretty good. What I've learned is that performance is important, but it's not the driving concern for most Ruby developers, especially those building web applications usually bounded by unrelated bottlenecks in IO or database access. But that's only what I've been able to gather from conversations with a few of you. Is there more we need to do? Should we keep going on performance, or are there other areas we should focus on? Do you have cases where JRuby's performance doesn't meet your needs?

JRuby performance future is largely an open question right now. A stock JRuby install performs really well, "better enough" that many folks are using it for performance-sensitive apps already. We know there's bottlenecks, but we've solving them as they come up, and we're on the downward slope. Outside of bottlenecks, do we have room to grow? You bet we do. I've got prototype and "experimental" features already implemented and yet to be explored that will improve JRuby's performance even more. Of course there's always tradeoffs. You might have to accept a larger memory footprint, or you may have to turn off some edge-case features of Ruby that incur automatic performance handicaps. And some of the wildest improvements will depend on dynamic invocation support (hopefully in JDK 7) and a host of other features (almost certain to be available in the OpenJDK "Multi-language VM" subproject). But where performance improvements are needed, they're going to happen, and if I have any say they're going to happen in such a way that all other JVM languages can benefit as well. I'm looking to you folks to help us prioritize performance and point us in the right direction for your needs.

JRuby makes the JVM and the Java platform really shine, with excellent language performance and a "friendlier" face on top of all those libraries and all that JVM magic.

I think this is an area we've only just started to realize. Because JRuby is hosted on the JVM, we have access to the best JIT technology, the best GC technology, and the best collection of libraries ever combined into a single platform. Say what you will about Java. You may love the language or you may hate it...but it's becoming more and more obvious that the JVM is about a lot more than Java. JRuby is, to my knowledge, the only time a non-JVM language has been ported to the JVM and used for real-world, production deployments of a framework never designed with the JVM in mind. We've taken an unspecified single-implementation language (Matz's Ruby) and its key application framework, (Rails) and delivered a hosting and deployment option that at least parallels the original and in many ways exceeds it. And this is only the first such case...the Jython guys now have Django working, and it's only a matter of time before Jython becomes a real-world usable platform for Python web development. And there's already work being done to make Merb--a framework inspired by Rails but without many of Rails' warts--run perfectly in JRuby. And it's all open source, from the JVM up. This is your future to create.

I think the next phase for JRuby will bring tighter, cleaner integration with the rest of the Java platform. Already you can call any Java-based library as though it were just another piece of Ruby code. But it's not as seamless as we'd like. Some issues, like choosing the right target method or coercing types appropriately, are issues all dynamic languages face calling into static-typed code. Groovy has various features we're likely to copy, features like explicit casting and coercing of types and limited static type declaration at the edges. Frameworks like the DLR from Microsoft have a similar approach, since they've been designed to make new languages "first class" from day one. We will work to find ways to solve these sorts of problems for all JVM languages at the same time we solve them for JRuby. But there's also a lot that needs to come from Ruby users. What can we do to make the JVM and all those libraries work for you?

I guess there's a simple bottom line to all this. JRuby is an OSS project driven mostly by community contributors (5 out of 8 committers working in their free time and hundreds of others contributing patches and bug reports), based on an OSS platform (not only OpenJDK, but a culture of Free software and open source that permeates the entire Java ecosystem), hosting OSS frameworks and libraries (Rails, Merb, and the host of other apps in the Ruby world). All this is meaningless without you and your applications. We're ready to pour our effort into making this platform work for you. Are you ready to help us?

21 comments:

aemadrid said...

I think you should consider supporting Rack based apps/frameworks as your next target. Most exciting new frameworks, including Merb, are going that route and I think it already provides a decent, standard way to use other several web servers.

AEM

James Britt said...

Ditto on Rack. It may make it easier for JRuby to hook into the dozen or so Ruby Web frameworks currently using it.

Nice that there's GlassFish for Rails, but GlassFish for Ruby Web App of Choice would surely rock.

Anonymous said...

why is that if it is compatible with the latest versions of Ruby the language, that you need special announcements and work to support various frameworks.

Sammy Larbi said...

"Is there more we need to do? Should we keep going on performance, or are there other areas we should focus on? Do you have cases where JRuby's performance doesn't meet your needs?"

I've been using it for bioinformatics research, but as the genomes I work with get bigger it is becoming unacceptably slow, and I'm having to move languages.

It's a fringe case I know, but there /is/ a bio ruby group, at least. =)

I have some interest in AI algorithms too, and that can get quite slow.

I guess though, asking the current users isn't going to get you as good a response as asking non-users, so that's why I bring these up.

It's something that most people in those areas and similar ones wouldn't have been able to answer because they don't see the possibility of working with Ruby (or JRuby) to begin with (because of performance reasons, even if writing the algorithms is a thousand times more pleasurable).

tmpk said...

Memory consumption and debug tools are the biggest concern here.

We're IO bound so the more instances we can squeeze on each box, the better. And of course developer time is a much larger concern, so anything that helps make us more productive would be appreciated; better debug tools are an example.

JRuby looks like it has the deployment angle covered, which is welcome. Also the use of native threads, since we've been bitten by MRI's green threads quite often; we were willing to put up with it due to the memory consumption issue.

goekenator said...

I also wonder about startup time. If I were to make some wild requests:

- Startup time for applications such as little Linux scripts.
- Speed not as compared to MRI but compared to other JVM languages.

I would love to play with an ESB based on ruby message handling and YAML messages (versus XML). I have not tried this, but ruby seems to be a good match for quickly parsing, transforming, and routing messages. Combined with AMQP, you could derive a very interesting system.

Anonymous said...

You talk about JRuby being ready to roll for serious web apps, but how "ready" is glassfish V3 GEM for production? It sounds like the best deployment option, but is it ready to be used in a production environment or are we stuck with jmongrels for a while longer until it is? Any idea on that timeline?

Anonymous said...

Great work with JRuby guys. I'm also going to suggest supporting Rack based apps/frameworks. I think the ruby community is really moving into non-rails based frameworks including Merb and my personal favorite, Ramaze. I haven't tried these with JRuby yet, but I think they are important apps to support.

James Britt said...

" ... and my personal favorite, Ramaze. I haven't tried these with JRuby yet, but I think they are important apps to support."


I tried Jruby + Ramaze earlier today.
Seemed OK, with the big issue being database support. I wanted to use either Og or Sequel with Sqlite3, but sqlite3 has native code dependencies and I could not install the gem under JRuby.

However, Kirbybase (without Sequel) worked fine.

I think Og still chokes JRuby.

Anonymous said...

@sammy larbi: If you want memory efficiency, you don't want Java. Most useful scripting languages (Ruby, Perl, Python, Matlab, ...) have nice C interfaces, and in C you can control memory use.

Ed Brannin said...

@James: If you just want sqlite for its lightweight flavor (and don't need to read the database from non-Java programs), you should look at Derby.

James Britt said...

@Ed_Brannin: Thanks. I forgot about Derby; I'll look at it again.


(What I *really* want is to use Og or Sequel to wrap the raw DB calls in something Rubyesque, and I don't think either of those two support Derby. )

Anonymous said...

Has anyone tried this with Tomcat?
Is there a new jruby-complete jar or should RC1 work.

Anonymous said...

Ok, I did found the new jar jruby-complete-1.1RC2.jar, it was put out last night. I am still having the same problem because it's not able to find custom gems. Help! I am using warbler to create the war. I can see all the gems in web-inf/gem.... While loading rails it can't find say -ruport. Before ithe deployment was actually exploding the gems to some 'default user' directory and finding them there. May be I am just rambling, I hope some of this make sense to you guys.

Regards,
Peter

Graham Miller said...

I know this may not qualify as "help", but I did leave feedback on this bug
http://jira.codehaus.org/browse/JRUBY-939
pertaining to RC2. It's the only thing so far that we've found. Thanks! (Having trouble posting to the mailing list right now, will try again later.)

Anonymous said...

Graham,

So how do I get past this issue that
the jruby rc2 is not able to find the gems?
no such file to load -- ruport
file:/C:/Program Files/Apache Software Foundation/Tomcat 6.0/webapps/Sodexho/WEB-INF/lib/jruby-complete-1.1RC2.jar!/META-INF/jruby.home/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'

Thanks,
Peter

Anonymous said...

I guess nobody reads this blog,
anyway the problem to me is the age old issue of windows directory structure versus unix. So I unpacked the jar and made the following change method lib_lib_dirs_for in GemPathSearcher and the problem went away.


def lib_dirs_for(spec)
"#{spec.full_gem_path.gsub! File::ALT_SEPARATOR, File::SEPARATOR}/{#{spec.require_paths.join(',')}}"
end

Charles Oliver Nutter said...

anonymous: Have you filed a bug for that? If not, please do, providing your fix. That will really help us make sure it's fixed in RC3.

Heri said...

I almost cried when I saw this:

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=jruby

We definitely gotta work more on performance and get far above on this list: http://shootout.alioth.debian.org/.

Also on this list:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Heri said...

Anonymous,

I personally use the jetty_rails gem on production systems instead of glassfish_rails (which is unstable).
You can modify this jetty gem to add https support quite easily.

It's fast. My pages finish loading faster than cRuby mongrel as jetty_rails spews out static data like .js .css and .jpeg very quickly. About 2.2x improvement on rails .rb processing and 12x on static files.

Anonymous said...

Under performance:

Has one of the key trampoline functions that only appeared to be inlining been fixed?