There are many different implementations of Ruby , and each has their own set of disadvantages and advantages.
JRuby has many advantages, including
- Performance benefits in some applications 
- True system threads 
- Access to the Java Toolchain 
As explained in the http://www.restlessprogrammer.com/2013/02/multi-threading-in-jruby.html linked earlier, JRuby runs on the Java Virtual Machine (JVM) , allowing it to provide 1:1 system threads .
While Matz's Ruby Interpreter (MRI) provides threads, they're constrained by the MRI implementation of a Global Interpreter Lock .
Why does this matter?
Let's consider this thought experiment:
You have many large .csv files, each about 1GB large. You'd like to process each of them using a simple process:
- Split each file into workable pieces
- Read each piece concurrently
So, you end up writing something like this 
threads = Dir[File.join(File.dirname("path/to/my", "*.csv"))].each do |file| Thread.new do CSV.open(file, 'r+') do |csv| ... end end end # Waits for threads to finish, returns each thread in turn when done threads.map(&:join)
But the process is taking forever! So, you open up your ActivityMonitor (or Task Manager) to see what's going on. Maybe the program hung!
Nope. You see that your ruby process, of which there's only one entry in your ActivityMonitor, is running at 100%. It even has more than one thread! But then, on your processor view, you notice that only one core is being maxxed out.
What gives? MRI Ruby is doing its best to provide the perception of a program running in multiple threads. In fact, each process is running in multiple threads; however, you can think of the MRI implementation as running these threads within the confines of a single parent thread.
You've probably guessed by now that JRuby is an implementation which is able to bypass this MRI limitation.
In JRuby, each thread runs as a thread on the JVM, where it's usually mapped to a native operating system thread after some fancy footwork by the JVM. .
So in JRuby, running a similar convoluted example, we'd see something like this:
Ok, I admit, the examples in the screenshots aren't exactly real-world use-cases, but you get the point: JRuby tangibly grants you more power. Now, all you have to do is not fuck it up! Check out the list below for reading material to get you quick-started on this last point, of not screwing up threads, state, etc. in JRuby.
-  http://en.wikipedia.org/wiki/Ruby_(programming_language)#Alternate_implementations
-  http://stackoverflow.com/a/13448080/1162491
-  http://www.restlessprogrammer.com/2013/02/multi-threading-in-jruby.html
-  https://github.com/jruby/jruby/wiki/CallingJavaFromJRuby
-  http://en.wikipedia.org/wiki/Java_virtual_machine
-  http://blog.jamesdbloom.com/JVMInternals.html
-  http://www.jstorimer.com/blogs/workingwithcode/8085491-nobody-understands-the-gil
-  Keep in mind, this is not a great example, as we read the entire file into memory just for demonstrating a long running process.
-  http://www.dreamincode.net/forums/topic/166151-threading/
-  https://github.com/jruby/jruby/wiki/Concurrency-in-jruby
-  http://blog.headius.com/2008/02/ruby-threadraise-threadkill-timeoutrb.html
-  http://metaphysicaldeveloper.wordpress.com/2010/12/16/high-level-concurrency-with-jruby-and-akka-actors/