I’ve been spending some time dipping my toes in patch contribution for JRuby recently. I started with a few easy, isolated, spec issues, and have since been working my way into more entrenched problems. The past few weeks I spent a good bit of time toying with solutions to JRUBY-2810: “IO foreach performance is slower than MRI”. The exercise was interesting enough, that I thought it might be worth posting here. This isn’t meant to be a study of the JRuby code in particular, but more-so in the thought process of diagnosing a performance problem in foreign code. (more…)
Posts Tagged ‘JRuby’
JRuby “IO.foreach” Performance
Tuesday, November 3rd, 2009Distilling JRuby: The JIT Compiler
Tuesday, October 6th, 2009
The JIT compiler in JRuby is a relatively new creation for JRuby. Of course, the initial approach taken for the JRuby platform was the most straightforward: parse and interpret the code incrementally as the program executes, traversing the AST. As time went on, the JRuby team have taken a bunch of steps to improve the performance of JRuby, most of which have involved shortcutting the consistent, but also slow and indirect interpreter model. The JIT compiler is probably one of the most aggressive and technically complex steps taken to date.
JIT compilers are a novel idea: take some code in an “intermediate form”, and, given some heuristics, compile it into a “more native” representation, with the expectation that the more native version will perform faster, and allow for more optimizations by the underlying platform. If some optimizations can be thrown into the more native form in the process, all the better.
Java, as an example, has had a JIT compiler for several years now. In fact, Java was, for many developers, the first time they heard the term JIT; so much so that many developers I know think the “J” in JIT stands for “Java”. In fact, JIT stands for Just-In-Time. Smalltalker’s may recognize the term “Dynamic Translation” instead.
Anyway, when the Java runtime determines code is eligible for native compilation (frequency of execution is one of the primary parameters), it diverts the execution of the code, so it can perform some fancy hoop-jumping to turn the Java bytecode into platform-specific native instructions, thereby removing any cost of bytecode interpretation, and also throwing some nifty optimizations into the compiled code. From that point forward, the native code will be used for execution, unless and until it has been invalidated by changing assumptions.
JRuby’s JIT compiler is similar in nature, the primary difference being the source and destination formats. In Java the source format is Java bytecode, and the destination format is native machine instructions. Conversely, in JRuby, the source format is the JRuby AST, and the destination format is Java bytecode. Perhaps the most fascinating aspect of the JRuby JIT compiler is that it benefits from both the initial compilation into Java bytecode, and then later, when Java may attempt to translate the JRuby-generated bytecode into native machine instructions. So effectively, it is possible to get a double-JIT on your executing code.
Generating Java bytecode from interpreted Ruby code is no small feat, however; so, without further ado, let’s start the tour of JRuby’s JIT!
Distilling JRuby: Tracking Scope
Friday, September 25th, 2009One of the things that is always going on in any programming language is managing the scope of variables. Scope is central to both how we code, as well as how a program executes. Even just in methods, how variables are scoped can be a point of great contention (particularly in code reviews).
When it comes to implementing a programming language like JRuby, the concept of a scope permeates everything. After all, someone needs to track what variables are available at each level in the activation stack, and when the stack unwinds (either through normal use, or due to an exception), someone needs to unbind the variables in scope with it.
And, of course, Ruby has closures, which means that you have to carry (aka capture) free variables into scope of the closure. But, Ruby also has instance and class eval’ed code blocks. Those have an entirely different scope. When you get down to it, Ruby is bound to test a scope algorithm’s limits.
So how does JRuby do it?
JRuby 1.4 Plan Details Discussed
Monday, September 21st, 2009The JRuby team has posted some key JRuby 1.4 details over at the Engine Yard blog.
Of high-level note:
- Ruby 1.8.7 is the new Baseline – This promises a number of library changes and backports from 1.9. To see the 1.8.7 changes you can look here.
- Ruby 1.9 Compatibility Improvements - As mentioned in the blog entry, Ruby 1.9 is a moving target, however they are moving a lot closer to having major libraries working as desired. Some high-visibility features (like Fibers) are still on the pending list, however.
- New YAML Parser - Ola Bini re-visited the YAML parser in Ruby recently (he has blogged about the creation of the new parser and how he ported it). The new parser, Yecht, is said to be completely compatible with Syck (the Ruby parser), warts and all.
- Java Method Dispatch Improvements - One of the major promised features of 1.4 for quite a while has been improvements to the Java integration; they have been wanting to formalize this portion of the language for sometime. This involves calling Java methods, calling overloaded Java methods, the coersion of types (Java string <–> Ruby string), etc. Charles Nutter has posted a very detailed, developer-centric breakdown of the plans in this integration on the Developer mailing list (which goes beyond what’s available in the blog entry). Certainly an interesting read.
- Java Class Generation via JRuby - JRuby will finally be able to construct runtime-available Java classes on the Java classpath. This will be available on-demand only, however that could be quite handy in a number of difficult integration scenarios.
This set of features is exciting to me, particularly for the Java integration features. The current Java integration functions, but can be somewhat tempermental, and can end with surprising results at times (I have learned this the hard way via hand-coding Swing and SWT apps).
Additionally, one of the killer features of Scala, in my opinion, is its ability to interact seamlessly with Java libraries at compile-time (create a class in Scala, and code against it in Java). While the semantics defined for JRuby are more runtime-centric for now, it does provide an ability to construct something that can be fed into Java APIs at runtime that expect certain “inferred” contracts to exist (such as the Jersey example they used in the original post).
Distilling JRuby: Method Dispatching 101
Wednesday, September 16th, 2009
To better understand how JRuby combines the Java world with the Ruby world, I have recently been delving into the source code (available via git), and while the implementation there-in is always bound to evolve and change, it seemed that there would probably be some value in me documenting my journey through the guts of JRuby.
JRuby is a huge beast, so it can be hard to find a place to start – nonetheless, as the joke goes you eat an elephant one bite at a time, so I figured I’d start somewhere at least somewhat familiar.
One of the first areas I picked up was the method dispatch code. This is an area I have seen discussed through a number of blog entries by various JRuby committers; and given the criticality of the code in this area, I knew it was probably a fairly mainstream section of functionality; heavily used by a running JRuby application.
Unfortunately, it is also right in the middle of the implementation, so it’s a bit like starting to eat the elephant right in the middle. Nonetheless, I have made my way through a good bit of it, and learned a lot in the process, so let’s get started.
(more…)
Taking Advantage of Java in JRuby
Wednesday, September 9th, 2009Tom Enebo and Charles Nutter have posted a couple of entries over at the EngineYard Blog on accessing Java libraries from JRuby.
For those who may not be familiar, Tom Enebo and Charles Nutter were full-time Sun employees until late July when they switched companies to Engine Yard. As many others have said, it’s a different experience (and in my opinion, a very good one) seeing JRuby posts show up on the EngineYard blog.
You have to make a decision at some point when developing a JRuby application as to whether or not you are going to hide the ‘Java’ in your JRuby application from the main bulk of your code. Obviously, if you are developing a Swing GUI, it’s pretty much a foregone conclusion that it’s a JRuby app, and JRuby alone. On the other hand, it’s very possible now-a-days to code a Rails app that can run concurrently on JRuby, MRI, and any other compliant platform.
No answer is ‘right’. Each approach has its own virtues, and it really depends on your goals. A Java developer who simply wants to make coding Java apps easier could easily switch to JRuby and sprinkle Java references throughout their app. On the flip-side, you may just choose to deploy an existing Ruby app on JRuby for it’s compelling performance characteristics and its alternative deployment/scalability options; or perhaps your company would rather manage a Glassfish cluster than a Mongrel cluster – there are a variety of possible reasons.
Tom’s article (part 2) delves a little deeper into the influence of Java from an API perspective (as opposed to the basic Java-integration language constructs). His comments on delegation are compelling:
Delegation as a concept is not specific to Ruby, but is worth bringing up. Why decorate a Java class and get all of that Java class’s methods exposed when you can hide them behind another Ruby class that only exposes what you want? This is especially powerful when you want to write a common API that works across multiple Ruby implementations (e.g. JRuby, MRI, and Rubinius), but has different native backends.
In practice, even if you have committed to JRuby as your platform and have Java libraries referenced all over the place, it can still be very valuable to abstract APIs around the original Java implementation – if for no other reason than Java APIs needing some TLC to feel natural in Ruby. Likewise, there are cases where using Java libraries as the driver for a particular component of your application may give you a competitive advantage on JRuby.
In that vein, I was recently working on a high-concurrency component of a JRuby application. In my opinion, the Java libraries for concurrency are much further evolved than those in Ruby; particularly after the advent of java.util.concurrent in Java 5. One of those areas where Ruby is lacking is the existence of a read-write lock. Jonah Burke previously blogged about implementing a read-write lock using the standard Ruby mutex objects. His implementation is simple, well-implemented, and should be quite reliable. However, Java’s ReentrantReadWriteLock is fully integrated into the underlying Java platform, including in the instrumentation libraries (detailed briefly here). To me, if you plan to run on a Java platform, being able to independently monitor locks held by the Ruby runtime is a Good Thing.
Here is a simple JRuby implementation of a ReadWriteLock that uses a Java lock via delegation:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 | require 'java' class ReadWriteLock include_package 'java.util.concurrent.locks' def initialize @java_lock = ReentrantReadWriteLock.new end def read(&block) read_lock = @java_lock.read_lock read_lock.lock begin block.call ensure read_lock.unlock end end def write(&block) write_lock = @java_lock.write_lock write_lock.lock begin block.call ensure write_lock.unlock end end end |
As you can see, JRuby makes using Java objects and extending them very straightforward.
This particular implementation is not 100% API-compatible with the one provided by Jonah, however with a little manipulation it could be easily (I’ll leave it as an exercise to the reader). This is really more of an example of how Java can provide the underlying engine for Ruby libraries when running on JRuby (this is how the majority of JRuby is implemented, after all) – and if this were API compatible with Jonah’s, it’d simply be a matter of constructing this in an isolated factory method, and switching implementations then becomes simply a matter of flipping a flag.
Note that instead of delegation, you could also simply extend the existing Java object with more goodies. Here is an alternate implementation of these same block methods that simply appends these methods to the Java class itself:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | require 'java' class java::util::concurrent::locks::ReentrantReadWriteLock def read(&block) read_lock = self.read_lock read_lock.lock begin block.call ensure read_lock.unlock end end def write(&block) write_lock = self.write_lock write_lock.lock begin block.call ensure write_lock.unlock end end end |
In practice this works almost identically to the first example. This implementation has some API-leakage (the Java methods on ReentrantReadWriteLock are available to call by the client code), but also has one less object involved, as the methods are added to the Java lock class itself, rather than provided by a proxy object. Which approach you would use for your particular use-case is really dependent upon the scenario in question, and your goals for the API.
Either way for this example, the core usage of this library is identical irrespective of which implementation you choose:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | lock = ReadWriteLock.new # Alternatively, the second example would be created this way: # require 'java' # import java.util.concurrent.locks.ReentrantReadWriteLock # lock = ReentrantReadWriteLock.new # Usage is identical lock.read { puts 'Executing with read lock' } lock.write { puts 'Executing with write lock' } |