Gluttonous

JRuby: A Ruby VM in Java

Posted by kev Sat, 15 Oct 2005 01:24:36 GMT

jruby.sourceforge.net

Charles Oliver Nutter, presenting

Who Am I?

• Charles Oliver Nutter: headius@headius.com
• Senior Architect/Technologist at Ventura Corp

Part1: Past and Present

• What is JRuby?
• Why JRuby?
• Peer Comparison
• The Real World

What is JRuby?

• A “100% Java” based Ruby interpreter
• Mostly 1.8 compatable
• Four years and 15 developers; currently 3-5 active and under heavy development
• Originally modeled on Ruby 1.6 code
• Tri-licensed: CPL, GPL, LGPL
• Sun J2SE 1.4 or higher (FOSS Javas in future)
• Java/Ruby integration getting better

Why JRuby?

• JVM provides native threading, generational GC, and extensive networking and database support
• Wealth of libraries and frameworks; large userbase, wide deployment
• Many Javaists would like to use Ruby more
• Java is “just another platform” for Ruby
• JRuby could help grow Ruby the language apart from C Ruby
• Sun, others very interested in dynamic (typed) languages on the JVM
• Javaists (by choice or by force) can help promote Ruby
• Java/Ruby integration merges best of both
• Ruby + J2EE = enterprise ruby that managers can swallow
• Ruby + J2ME… someday?

Demo 1: Java integration

• Ruby code mixed into java
• JDBC used for DB access (PostgreSQL 8.0)
• Mostly transparent object marshalling

Peers

• Jython - www.jython.org

  • Pythonists dig it
  • By far the most popular JVM dyn lang
  • Establisehd, stable, feature complete
  • Helpting to formally define/distinguish Python the language from Python the interpreter
  • Interpreted or compiled (runs Python bytecode, or compiles to Java)
  • Widely used

• Groovy - groovy.codehaus.org

  • Ruby-like syntax, some features from Nice
  • Seamless Java integration, sometimes with perf hit
  • First dyn language JSR
  • Lots of momentum
  • Interpreted (JIT) or compiled offline to Java code
• SISC - sisc.sourceforge.nt
  • JRuby redesign follows similar patterns
• Many others

The Real World

• RDT: A Ruby IDE for Eclipse; rubyeclipse.sourceforge.net
• jEdit: A Multi-Language Code Editor; www.jedit.org
• DataVision: Java-based Reporting Software; datavision.sourceforge.net
• Internal projects
• Need more

How “Ruby” is it?

• Of 1049 Rubicon tests, 80% succeed
• Temporary incompatibilities
  • Ruby thread semantics differ from Java’s
  • No continuations
  • Twice as slow (half as fast?) as C or worse
  • YAML: no up-to-date, working pure Ruby or Java parsers
  • still missing a few 1.8 methods
• Permanent incompatibilities
  • System calls, C-language Ruby extensions, anything to do with C
  • Platform-specifics: file stats, permissions, process launching, signals

Part Two: The Future

• Continuing to improve compatibility
• Running mainstream Ruby apps
• Improving Java integration
• Speeding up
• The New JRuby

What needs to change?

h4. What needs to change?

• JRuby deficiencies ( as of 0.8.2)
  • Stack depth (~ fib(280))
  • Threading and thread semantics
  • Continuations support
  • Speed
  • Consistency, maintainability
  • Compilation
  • Better use of Java’s strengths
  • Tigher integration between Java and Ruby
• Ruby deficienies (as of 1.8):
  • Stack depth (~ fib(1325))
  • Native threading
  • Speed
  • Compilation

The New JRuby

• Stackless; Continuation Passing Style (roughly)
• Iterative interpreter
• min threading model
• Compilation to Java bytecodes, offline and JIT
• Pluggable architecture
• Seamless, powerful Ruby/Java integration
• Behave in controlled environments
• FAST

Milestones and progress

• Stackless, iterative proof of concept (POC) (Sept 15, complete)
• Redesign, refactoring of POC (Oct)
• Reimpl of interpreter based on POC (Nov)
• Reimpl of built-in classes (Nov-Jan)
• Threading engine (Jan)
• Tri-call optimizations (Jan)
• Continuations (Jan)
• Compilation (Feb - Apr)
• Complete for JavaONe 2006

Demo 2: Fibonacci

• Recursive fib algorithm (contrived, I know)
• Jruby 0.8.2: shallow
• Ruby: deeper
• JRuby “stackless” POC: deepest

(Demo of doing fib 30000 in JRuby! Pretty cool.) (Somewhat longer demo of 150000. Also cool.)

What Else?

• YARV bytecode execution
• MetaRuby’s “Ruby in Ruby” useful to JRuby
• drb proxy to RMI
• ActiveRecord JDBC connector
• WEBrick-mimicking servlets
• Other ideas?

Part Three: What now?

• Redesign is in full swing
• Heavy refactoring of JRuby core
• A better Ruby than ruby?
• Help Wanted!
  • zlib implementation using Ruby-Java integration
  • FIle locking using Java’s NIO (New I/O)
  • Feature-complete YAML support
  • Running mainstream Ruby apps, isolating and reporting errors
  • Help with new design and with refactoring effort
  • Tangibles

Q&A

• “JRuby”:http://jruby.sourceforge.net
  • SF project page”:http://sourceforge.net/projects/jruby
• JRuby mailing lists on SF
• Charles Oliver Nutter: headius@headius.com
• Thanks to:
  • Thomas ENebo: JRuby project manager
  • Kelly Nawrocke: Jruby developer
  • David Corbin: JRuby developer, RDT developert
  • Special thanks to Jan Ame Petersen, original JRubyist

REAL Q/A

• ???: About YAML - parser written in C, have C to Java translators been tried?

  • Charles: Might not produce code that would wire in nicely; focusing in pure Ruby implementation.

• David Black: What about things that it would be nice if they were different than they currently exist in C Ruby - for instance, similar behavior often goes through different code paths? Can you change those things? Will it make it less Ruby?

  • Charles: Mainly taken perspective that we are following what Ruby does and following what Matz and company do. Having this other platform will point out inconsistencies; some things are unfollowable. Having two places where behavior is implemented shows inconsistencies.

• ???: Is JRuby going to be reentrant? Will you be able to run multiple JRuby instances in the same process?

  • Charles: Yes, unable to control where calls are coming from, so needs to be re-entrant. Either that or able to run multiple lightweight interpreters in the same VM and then manage state. Not thread safe at this point but hopefully that will change.

• Duane Johnson: In the demo, the each iterator isn’t acting very Ruby-like.

  • Charles: The demo is kind of put together to show everything. What would probably be better would be a Ruby-Java layer that does “rubyfication.” Code as demo’d was more javaish but still simpler than real Java.