Charles Oliver Nutter schrieb: [...] > Currently, even if you declare a > type, it will still dispatch based on the runtime set of methods for > that type. So in your example, if I have replaced the foo() method on > Foo with some other piece of code, will statically declaring my > variables as type Foo dispatch to the original foo() method or the one > I've replaced?
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. > This is the conundrum I face in Ruby, where we already > can gather type feedback to know a variable is always X, but still > need to check if X is being modified so our direct calls are valid. 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. > Some of this exists already in JRuby; if you call a numeric method > directly against a Fixnum (boxed 64-bit integer), it will go straight > in and even inline the logic. Upcoming compiler work will also start > to add type and method guards to inlined/optimized versions of code. > But the mutability of classes common to both Ruby and Groovy means > unguarded direct calls will probably always be suspect. 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. 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 -~----------~----~----~----~------~----~------~--~---
