Sorry for the unsolicited promotion of JRuby and my own blog, but I
have been keeping a record of updates to JRuby along with musings on
the future of Ruby and Java playing together at
http://headius.blogspot.com. For those of you like me, caught between
worlds, I will frequently provide updates on the progress of JRuby and
the future of Ruby applications running on Java. My post today updates
the progress of getting Rails and IRB running, with a long discussion
of JRuby’s design goals, performance woes, and promises for the
future. Naturally, I’d like an audience, but I’d also like to dispel
the continuing rumors that JRuby is “dead”.
For those of you completely uninterested in Ruby-on-Java, you can
safely disregard this email. 
Thank you!
Hey Charles:
Tim B. mentioned that JRuby uses Java native threads to implement
Rubys’ threads. [1] Do you guys have any sort of publically posted
comparisons of performance of threading between Ruby & JRuby? I don’t
even know enough about concurrency to know what are good ways to
measure performance, but I think I’d find it interesting reading
anyway.
Francis
[1] ongoing by Tim Bray · Ruby on Rome
That’s a good question, Francis. I’m afraid no formal comparison of
JRuby’s threads versus Ruby’s threads has ever been done. Threading
has been both an advantage and a disadvantage of JRuby.
- Native threads allow ruby code under JRuby to utilize multiple
processors, ultimately scaling better to big iron, but…
- A hard 1:1 tie between Ruby and Java threads means that many Ruby
thread operations are difficult or impossible to support because
Java’s own threads do not support those operations. Cross-threading
hacks are a poor substitute for access to and control of a true thread
scheduler
If we put aside JRuby’s interpreter performance issues for a moment,
it would be safe to assume that JRuby’s threading today would in
general scale and perform better than C Ruby, since it would
automatically provide a truly threaded environment for ruby code. That
said, it’s difficult to quantify that performance benefit in light of
the current unoptimized JRuby interpreter. You could scale it better,
but you’d be scalling a much slower base interpreter.
In order to address the second point above, we have chosen to
implement our own “green” non-native threading subsystem in JRuby.
This will allow us to build a thread scheduler and threading semantics
that match the way Ruby wants threads to work. However, since Tim B.
and others have expressed a strong interest in keeping JRuby
native-threaded, we are planning to back those “green” threads with a
configurable pool of natives. For applications that want or warrant
true 1:1 threading, there will be no issue…simply turn on 1:1 and it
will run as it runs today. For applications that want pure green
threads, it will be just as simple; turn it on and all Ruby threads
will run in a single Java thread. However, for those middle cases
where we want m Ruby threads to be backed by n Java threads, we will
also support m:n threading, providing three different mechanisms for
scaling up Ruby applications.
So in the end, I don’t have any definitive answer to give you. JRuby’s
current threading scales better; JRuby’s current slow interpreter does
not. JRuby’s threading does not support all Ruby threading operations
well currently. All these issues are being addressed in the next six
months (or perhaps sooner if we can get Rails running). Does any of
this answer your question?
–
Charles Oliver N. @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com
Ahh JSR 223. 223 is, at its core, a more feature-complete and
standardized version of the Bean Scripting Framework (BSF). It
provides a standard mechanism whereby alternative JVM languages
(primarily targetted at so-called “scripting” languages) can be
plugged into and interact with Java and the rest of the JVM. BSF
provides similar capabilities; you can register a named language
interpreter, bind objects into its execution context, and send
snippits of code to that interpreter to be executed. 223 mainly
standardizes a lot of this and potentially builds that capability into
Java out-of-the-box, rather than via a third-party library.
There’s shades of not-invented-here, but BSF certainly is showing its
age (it does not, for example, use more recent versions of collection
classes, nor does it take advantage of recent JVM advancements). 223
will probably be good for Java as a whole, and once it’s physically
released we’ll have JRuby connectors for it soon after. We also
currently provide our own java integration layers that are arguably
simpler and more “ruby-like” than what BSF or 223 provide. There’s
something for all tastes, I suppose.
223 does not, however, provide a generic way to hook any arbitrary
interpreter such as C Ruby into the JVM. Using any native-language
interpreters to manipulate Java objects and the JVM itself requires
considerably more work, since plugging native code into the JVM is far
from easy. The “rjni” project does exactly that, though I can’t
comment on how well it works or whether it’s currently being
maintained.
On 3/2/06, Charles O Nutter [email protected] wrote:
For those of you completely uninterested in Ruby-on-Java, you can
safely disregard this email.
Thank you!
Thanks for the notice, I’ll keep an eye on your blog.
And now we talk about ruby & java, I’ll take the opportunity to ask a
question I haven’t had the possibility to answer myself: what will
JSR223 give as possibility? Is it a way for ruby (the C version) to
access java classes? JSR223 started with a limited scope (web apps)
that was widened later on, but up to what point?
Raph