Charles Oliver Nutter schrieb: > On Mon, Nov 2, 2009 at 1:00 PM, Jochen Theodorou <[email protected]> wrote: >> to the replaced. I intend to let the compiler create a path where >> different types are assumed or ensured. If the compiler sees these types >> are modified or wrongly guessed, then it has to use the alternative >> path. replacing/adding a method modifies the type on which the method is >> replaced/added. Actually I know this will possibly make the methods >> bigger and I won't know if that effect will bypass the gain for a direct >> dispatch. I have to see how much makes sense once I have it working. but >> surely hotspot will have some work here. > > We have already begun to do this in some cases in JRuby, and will be > expanding on it more in the 1.5 work over the next few months. We will > do essentially what you describe, but based on runtime-profiled types. > If we see that an incoming argument is always a Fixnum, we'll try to > emit an optimized Fixnum path. This will be helped substantially be a > new compiler that can perform similar optimizations to Hotspot at a > Ruby level if we can feed it enough type information. Ideally we'll be > able to get runtime JRuby code to run as fast as static-typed code for > many cases. > > I'm hoping to avoid the problems of large method bodies by breaking > those bodies up into several synthetic methods. The fast path would be > in the main body, with slow paths in alternative bodies. The whole > thing would be stitched together with guards and static dispatches, so > it should all inline appropriately. Early results look very good; > we're able to get simple benchmarks within only a few times Java > performance.
my numbers show, that on integer based benchmarks Groovy could be around 30% slower than Java. The GSOC project which realizes a bytecode level optimizing compiler for Groovy shows this is very possible. The only reasons we don't go with that solution is that it requires Groovy to start two runtimes and as a library we cannot do that. So it would be only an option if Groovy is run from the command line. And for for example Grails this does not really look like an option. [...] > By "checking synchronized data" you mean checking a volatile field, > yes? We do the same, but it has been reduced to a single volatile > field per invocation. Eliminating the check improves performance, but > not as much as eliminating other dispatch overhead like argument > boxing or artificial stack-trace maintenance. one volatile is enough to cause problems to hotspot. I found that in Java 1.7 for example boxing is much less of a problem. If hotspot finds the path primitive, boxed, unboxed, then it removes those two surplus operations. So boxing by itself would not be a problem. But is you access the volatile before unboxing, then this path no longer works and hotspot won't remove the surplus boxing. Artificial stack-trace maintenance is something we don't do, so there is no problem for us. >> Well in Groovy it is reasonable to assume for a large set of classes >> that the class is not modified. Even working on a subset of methods >> might be possible. That works so well in Groovy because here you still >> tend to declare classes and not construct them at runtime. This means we >> can do that not only for numbers and other types known by the runtime, >> but also for classes the user declared. And of course some methods can >> get a fast path... I think of each, find, toString and such. > > We will make some of those assumptions, but generally only for numeric > algorithms. "each" and friends are all commonly reimplemented by > users, so they'll either need to be hand-inlined (via input from our > new compiler) or we'll have to hope that JVMs can catch up with > closure-based languages and inline closure calls across intermediate > megamorphic methods. why is it megamorphic for you guys? bye blackdrag -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
