On Fri, Sep 10, 2010 at 4:53 PM, Rémi Forax <[email protected]> wrote: > Like Matt says, I do variable-uses analysis.
Our new compiler will be able to do that. It's too hard to do against the AST (or hard enough that I don't want to try). Of course banking on "the new compiler" is always a gamble :) > You can push state on heap only between to block of N lines. > It's a kind of register spilling. I don't understand. Can you elaborate? > I also transform loop to function, i.e I cut before the loop > and integrate the loop and the loop body in a new function. > Because I use loop counter, I'm able to know if I need to aggregate > a loop and its inner loop or not. Yes, that's a split I've considered a few times, but the lack of variable-use analysis makes it impossible to know if it's safe. The reported JRuby bugs have thankfully only been for two cases: * A large flat method body, like the main body of a script * Large hash or array initializations that are usually all literals In the first case, splitting every N lines is easy. For the array and hash initialization, we have a path that will scan the AST to ensure all nodes are literals, and then break it up in some way. I haven't taken it farther because nobody's reported real-world cases that break...but I know they're out there. And of course, because JRuby is quite happy to bail out on a compilation and keep interpreting, users may or may not know that their code has been abandoned because of size. The dynopt work will only aggravate this, so I may do a two-pass compile: try to dynopt first, which is much faster but produces larger code, and if that fails fall back on the old inline-cached version that's lighter. It will still be faster than interpreting, and the compilation cost is not particularly high for the AST-based compiler (the IR-based compiler, with its multiple passes, is another matter...). 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). - Charlie -- 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.
