GoRuCo talk: JRuby: Ready for Prime Time

_Presented by Nick Sieger

JRuby: Java on the JVM

  • Currently targetting Ruby 1.8
  • Some work on trunk Ruby also
  • Started in 2002 with a direct C to Java port
  • JRuby aims to be a great way for running Ruby applications

But really… Java?

  • “COBOL of the Internet age”
  • Applets never fulfilled their promise—“Really cool!”
  • It’s Enterprisey!
  • “Write one, run anywhere” = “Write once, run nowhere” (Linux)

Seriously though…

  • Java brings battle-tested performance in the form of the JVM to Ruby
  • Makes up for deficiencies in C Ruby implementation

HotSpot: World Class VM

  • Dynamic analog to a C compiler
  • We used to optimize C by writing assembly
  • HotStop will compile your code down to bytecode
  • Determines “hot spots” in code and optimizes
    • Method inlining
    • Removing sync bottlenecks
    • Lots of other stuff

Threading

  • Ruby uses green threads
  • To use multiple CPUs you must have multiple processes
  • JRuby maps Ruby threads to Java native threads
  • Let you stay in-process and leverage multiple CPUs

Unicode

  • Ruby’s take—String is just a byte array
  • Java’s take—Everything is Unicode
  • JRuby must bridge this gap
  • Uses strings as byte arrays, but performs conversion

Garbage Collection

  • HotSpot has four GCs
  • Seperates long-lived and short-lived objects
  • Has options for optimizing GC performance
  • Lots of tuning variables
  • Ruby doesn’t have these

Runtime GUI

  • Java has a GUI to let you see CPU usage, threads, memory of running JVM
  • This could be hooked up to JRuby

JRuby Compiler

  • Not everything, but “good enough”
  • Can run in ahead-of-time or “just in time” (JIT) mode
  • Can fall back to interpretted mode
  • A compiler (JRuby Compiler) on top of another compiler (HotSpot)

Dual-Compilation

  • Multiple steps of compilation and optimization
  • Potentially have Ruby code compiled down to native code in the future

YARV Benchmarks – Ruby vs. JRuby

  • JRuby in interpretted mode slower than C Ruby, but getting better
  • JRuby in compiled mode is faster than C Ruby for some benchmarks

What’s Coming

  • 0.9.9 release coming on Monday
  • 0.9.9 is focused mostly on compatibility
  • 0.9.9 overall approx. 40% faster than 0.9.8

Compatibility – Test Suites

  • Using whatever we can find
  • Rubicon, Rubinius specs, ruby_test, Rails tests, RSpec’s specs, etc.
  • Two Google Summer of Code projects using RSpec to spec Ruby language

What’s Supported?

  • Rubygems
  • RSpec
  • Rails
  • Rake
  • Hpricot
  • Camping

Automated Builds

  • JRuby has over 900 tests

Demo Time!

  • Swing GUI in Ruby
    • Avoid ridiculous amount of Java code for Swing apps
  • RSpec

Deployment

  • WAR file is a web application in a package
  • J2EE spec says you can drop in WAR files for easy deployment (Sometimes not actually the case)
  • We want to allow the same database.yml file for JRuby deployment in the next few months
  • Mephisto running under JRuby from a WAR file. \m/

Q & A

  • Q: Is it possible to have Java class files dynamically compiled and loaded into Ruby?
  • A: There’s no straightforward way to do that. Ryan should do Java version of Ruby inline.
  • Q: Is there any effort for one-step JRuby web serving?
  • A: WAR plugin has support for Jetty. It would be good to have a Locomotive-style package. We haven’t done it yet. Still working on making it easier for plain vanilla Java deployment.
  • Q: Can you compare JRuby with Jython?
  • A: Similar projects. Jython is not as far along. Jython is compiled only. Serving same purpose for respective languages. Jython has been around longer. We’ve got some Jython users on the JRuby mailing list.

Resources

0 Responses to “GoRuCo talk: JRuby: Ready for Prime Time”