AOT and JIT are both important. If you could compile Rails ahead of time and increase performance 50-80% across the board, you'd do it. JIT is more important for running the "average" Ruby app that won't be pre-compiled...we want to be able to accept all comers into the JRuby world and have them all eventually see the same performance improvement from compilation.
JIT suffers from three issues: the hit from compiling at runtime (not huge, but not trivial), the delay before HotSpot gets to run its own JIT, and security limitations from generating code inside classloader-limited applications ( e.g. deploying a Ruby app in an applet or EE container).
AOT suffers from a potentially larger issue: you have to actually do the compilation and package things up in a new form. That would probably be cumbersome for day-to-day work (in esesence, destroying much of the "agility" Ruby programmers hold so dear).
The good thing, however, is that the code for each will be mostly the same.
Unlike Java, where you have to spit out a whole class at once, Ruby really just consists of "method bags". A given class is little more than pointers to code that understand how to manipulate that class's instance's state and call other methods. Because of that, the JRuby will compiler will necessarily be a "method compiler", turning individual methods into individual pieces of Java code, relocatable and redefineable at all times. Since method compilation can easily be done on only part of a class, it can be used for both AOT and JIT compilation.
So what will the compiler look like? A better question is what the COMPILERS will look like.
I intend to build several compilers. I'm sure most of them will probably end up in the trash, but hey, this is research man!
The compiler I'm working on at present is a full-on Java bytecode compiler using ASM. An AST visitor traverses the tree and generates Java bytecodes for each type of node. The resulting code looks, in general, like what we implement for builtin methods written in Java by hand. There will be a large number of methods that should be 100% compilable by this compiler, and by compiling they'll escape all the overhead of interpretation. However, I don't yet have a good strategy for instantiating blocks, since in Java no method's code can access the state of another method's code. This compiler is also fairly dependent on the current method-call and variable-scoping semantics, which are slated for redesign. It will be useful in the short term and as an exploratory project, and potentially in the long term if future runtime changes don't affect it too greatly.
I am also interested in building a compiler that generates either "JRuby bytecode" or more likely, YARV bytecode. There is some evidence that a simple bytecode machine implemented on top of the JVM yields extremely fast performance, sometimes on par with straight Java bytecode once Hotspot-optimized. I believe this is how Rhino achieves its speed...a simple interpreter loop and a stream of "_javascript_ bytecodes". The ability to run YARV bytecodes has another obvious benefit: YARV also plans an AOT compiler, and when it's finally released we'll start to see YARV-compiled code. Being able to run that code would be the ideal scenario, with the ability to recompile as JRuby bytecode less attractive.
Beyond this, there are other options that will be driven by our discoveries about Ruby's internals and our JRuby redesign plans. Reducing the overhead of method and block invocations is a top priority right now, and that will require considerable effort to redesign. Method, variable, and constant lookup are also slated for examination...we lose too much time looking things up and waste too much memory caching. We also need to drastically improve the speed of pure-interpreted mode, since it will always be necessary (and yes, this means that we will never move to a "compiled-only" model like Groovy).
There's one last little issue we'll have to address...Ruby's support for green threads and continuations. Any efforts to compile straight to Java bytecode will never support either...calls will deepen the stack and we'll never be able to switch threads or pull off a continuation. That's bad for apps that depend on green threading or continuations, but matz has also declared that Ruby 2.0 will support neither. I have various plans and schemes to support compilation AND green threading...some involve building that bytecode machine, and others are possible even with Java bytecode generation. However, those efforts are temporarily on hold until the true fate of green threads and continuations can be ascertained. matz has said that anyone really interested in keeping them better speak up now.
So, the short version, in my eyes:
- We must improve interpreted speed, since it will always, always be necessary. There's absolutely *no reason* we couldn't be as fast as C Ruby in interpreted mode.
- We must greatly improve the call logic. Too much memory is wasted, too many cycles are burned making calls. Too much complexity. Porting C code to Java has the effect of creating really bad Java code. Since much of the call stack is still based on that original code, a redesign is in progress.
- We must explore multiple compiler options, since there may be many types of compilation that have differing benefits for Ruby code. I'm willing to write compiler after compiler until we get this thing right...it's not that hard and it's very, very illustrative.
On 7/15/06, Paul Hammant
<[EMAIL PROTECTED]> wrote:
How is the JIT compiler going to work - with CGlib ?For what its worth I think an incrementally optimizing JRuby JIT compiler (not withstanding a subsequent JIT to native by the JVM) is waay more important than the AOT ( 'jrubyc' ) one.Confirm for me one thing though, whether AOT or JIT, the ruby executing natively on the JVM can dynamically create more Ruby and hand that to a classic interpreted JRuby executer. All transparently of course.- PaulOn Jul 14, 2006, at 8:07 AM, Charles O Nutter wrote:On 7/14/06, Nick Sieger < [EMAIL PROTECTED]> wrote: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 easierDownload IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo_______________________________________________Jruby-devel mailing list
-------------------------------------------------------------------------
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
--
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
