| 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.
- Paul On 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 easier Download 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
