On Jul 15, 2006, at 3:06 PM, Charles O Nutter wrote: > Well here's my mind dump on compilation. > > 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). >
Well this is a well understood rule with applet for sure (and some of the J2EE containers / web containers). A sandboxed applet may not (its veto'd) create a classloader. All its classes must come with it from the server. It was a speculative rule to prevent hacking ( I guess ). Now the applet security model is very good. One could assume a new rule for applets would be perfectly kosher: Sandboxed applets may create classloaders, but the classes contained therein are given the same rights as those that were shipped from the web server - the sandbox rules Basically this is some 'inherit rights' capability for classloader creation. It would require some real changes in Java beyond API/lang because you'd want to restrict it to 'same permissions as *me*' rather than 'same permissions as *this-or-that*' Does that sound useful? > 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. That's the key to success. Also why CGLib for Java is very successful. I wonder if there is some automagic test-driven > 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. > There's no never. James Gosling has spoken about Ruby and the JVM before. If you reach some critical mass, and Sun think this is compatible with the aims for Java, then something (say via JNI or Runtime.getRuntime().? or System.? can be made available in a forthcoming Java release that enables better thread interop. Then there was also JSR 121 and http://java.sun.com/developer/ technicalArticles/Programming/mvm that are worth reading but perhaps only minimally relevant. > 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. I hope there are many to help you. - Paul ------------------------------------------------------------------------- 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
