On Fri, Sep 10, 2010 at 8:11 PM, Charles Oliver Nutter <[email protected]>wrote:
> I suppose this is another technique both we and Jython use: execute > another way. JRuby has always had an interpreter, and I decided early > on when I joined the project that the interpreter should stay. I think > that's ultimately been a very good move, since it has both enabled > dynamic optimization (even without indy and method handles, which make > such optimization easier against compiled code) and given us a > fallback path when compilation fails for any reason (interpretation is > not fast...but it does execute, which is more than you can say for > compiled-only languages that hit bytecode or JIT limits and either > don't run or run incredibly slow). > > Python basically forced this on us because code objects are separate from names (so real dynamic binding). But it certainly nice to leverage that we can have potentially different implementations of a given code object, and of course do any profiling of usage. It's also conceivable that PBC might be cheaper from a cold startup perspective, but that's purely conjecture. Another thing that Jython should do in the future is to inline hot code objects so they don't first go through a large table switch to dispatch to the implementing method. Basically each Python module is compiled to a Java class with the top level module script a method; other function bodies are also methods. We then switch on the function index stored in the PyCode object to actually lookup and execute the method in question. There's almost certainly some additional targets in the callpath optimization we can do here too, similar to what we do in our type exposing mechanism today. - Jim -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
