On Sat, Sep 11, 2010 at 6:52 AM, Rémi Forax <[email protected]> wrote:
> Le 11/09/2010 04:11, Charles Oliver Nutter a écrit : > > 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). >> >> > > It's not hard ! > create a fresh scope, when you find a new variable wich > is not in the scope, find it in the old scope, and register that > the part of the script need this variable. > > > Of course banking on "the new compiler" is always a gamble :) >> >> If we use a new compiler in Jython, it will only be for hot code objects, or those that we have gradual typing information on. I'm pretty certain the current code layout is just fine for everything else. So this strategy mitigates any gamble. But see below... >> >>> 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? >> >> > > Because you know which variables you need, > for each block of code, you only use local variables, > between two blocks of code, you get the values of local > variables you will need later and store them in > heap allocated objects. Then you take the values > from the heap allocated objects to the next block of code. > > Now that's an interesting thought. Ever since the JVM language summit and Cliff Click's analysis of some Jython code, it's been quite obvious that storing every Python local name into the heap-allocated PyFrame associated with that function call is just a performance drain. Among other things, it defeats escape analysis. So it's good to think about this again. Maybe if we did some sort of barrier where we only did the stores into the PyFrame, either before a downcall or before coming out of an exception, we could preserve Python frame semantics without always paying their cost. This would be especially true if we guarded downcalls such that those not calling back into Python don't actually invoke the barrier. So in particular this could mean something with tight loops, often similar to this contrived code for i in xrange(1000): for j in xrange(1000): a = i * j # ... could get a lot cheaper, and ideally the JVM would elide away the allocations of PyInteger (wrapping int) - xrange certainly has no need to access the frame. We do something conceptually similar in our support of ContextGuard to minimize callpath costs in the with-statement. In particular, this allowed us to significantly reduce locking overhead; see Tobias Ivarsson's blog post on this http://journal.thobe.org/2009/07/improving-performance-in-jython.html Also, we actually do barriers in our support for the Python yield statement in generators/coroutines, where we store the Java local variables (not visible to Python itself, these are the unnamed variables such as the iterator returned from the above xrange function) in the PyFrame so they can be reconstituted upon the next iteration of the generator. So this approach is something we should definitely look at - it would require minimal hacking on the current compiler, plus the guard support. > As you already know, I don't think that an IR-based compiler > is a good idea. javac is not an IR-based compiler and > Java is fast. > > I think we have been convincing ourselves that we need an IR-based compiler. Tobias worked on one using SSA, but it proved to be a fair amount of work, and it has not been completed. Jython's current compiler is very simple/naive - AST directed, with the modest amount of scope analysis required for Python's lexical scoping (approx 360 lines). It has been pretty easy to hack on this compiler, whether a new language feature or the occasional bug fix. This is because of the strong degree of locality and easy correspondence from broken unit test to the resulting code path. Remi, you may be right - maybe we just need to continue to generate naive bytecode and let the JVM sort it out. Just somewhat better naive bytecode, that's all. - 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.
