Seeing Charlie's early progress on the compiler is exciting. I wanted to start a discussion on what the plans are for it, and how far down the spectrum of interpretation vs. compilation it should go.
In my opinion, the sweet spot is compilation as a speedup mechanism as long as it's transparent to the JRuby user or embedder and doesn't get in the way of the dynamic nature of Ruby code and the ability to change class behavior on the fly. I suspect that's the consensus since it's been pretty clear that JRuby's primary goal is to be as close as possible to a Ruby-compatible interpreter, and doing anything more towards strict compilation would probably jeopardize that. Still, thought it's worth asking.
Thoughts?
/Nick
Ruby is a very dynamic language, and therefore we need to be able to keep some level of dynamicity. However there's one thing we can usually count on: a given method may change from one chunk of code to another, but those chunks don't ever change themselves.
My intent with the compiler is that both ahead-of-time and just-in-time compilation will be possible without sacrificing any dynamicity. I believe both will be warranted in most run scenarios.
Ahead-of-time compilation will turn all .rb files into .class files, containing one main Java method for the straight through "load" of the file and additional Java methods for each Ruby method defined. The main Java method would contain code running at the "top level" as well as any class or module-scoped code. "Loading" a given .rb file, then, would be simple loading the corresponding class and executing that main method. This gives us the flexibility of open classes and "method bag" stubs with the simplified loading semantics of one-class-per-rb. I would see AOT compilation being used whereever you want things to be fast right away rather than waiting for a JIT cycle to kick in. For longer running apps like Rails, AOT may not be necessary...we'll JIT things pretty early on anyway...but for a short-lived app (like anything running bloody painful rdoc) AOT will make sense. We would also likely ship pre-compiled core libraries in the future, once issues related to loading those files have been worked out.
Just-in-time compilation will always happen, but we'll need to determine the heuristic for when to compile and when to re-compile code. This early version of the compiler is doing very little optimization; there's no culling of useless nodes, no whole-method variable optimization. However in the future we should be able to profile running methods over time and determine better ways to re-compile them, by optimizing Fixnum operations into primitive ops, for example. There will be a necessary hit to do the compilation, so we'll want to weigh that against the cost of running interpreted.
We're also likely to see additional impressive gains from Tom and my work on cleaning up, simplifying, and optimizing the method-call pipeline. Most methods in Ruby will be very call-intensive, since so many operators are methods and everything's an object. Optimizing the call pipe will pay dividends across the board, and general runtime optimization combined with an optimizing compiler might easily exceed C Ruby in performance.
--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ www.jruby.org
Application Architect @ www.ventera.com
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Jruby-devel mailing list Jruby-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jruby-devel
