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
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