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. > well for groovy that check itself is currently a problem, since it > involves checking synchronized data. If you do that for each and every > operation, than that means poor hotspot can do almost nothing and is > almost as slow as in the interpreted mode. For example in 1.7 I noticed > that if an int is boxed and then unboxed, then hotspot can eliminate the > boxing. But if before the unboxing a volatile field is accessed for > example, then hotspot won't do that. It is also a barrier for inlining. 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. > 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. - 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 -~----------~----~----~----~------~----~------~--~---
