John Wilson schrieb: > On 5/1/08, Jochen Theodorou <[EMAIL PROTECTED]> wrote: >> Charles Oliver Nutter schrieb: >> > Jochen Theodorou wrote: > [...] >> ok, let me try to explain what I think of... The current system in >> Groovy works like this: you have a narrow API, with some core that >> actually selects and executes the method call. Ng is more or less the >> same, but with a wide API. What I plan for the future is not no longer >> let the core execute the methods, instead they return handles to the >> call site and the call site will call the method for us. [...] > I have not found that a straightforward implementation helps with > performance (in fact it was slower with the initial implementation). I > think that this is because method selection is quite complicated (you > have to look at the types of the parameters and take Categories and > Monkey patching into account). So the JIT, in general, will not be > able to work out which method proxy object is returned from the > selection call. This means that it is not able to do any significant > inlining at the call site. Also you have to pass the actual parameters > twice, once to the selection method and once to the method proxy.
the purpose of this is not to have inlining of the method selection, it is to be able to avoid method selection. Inlining at the call site is impossible if you have to use Reflection, which is our old version. the new version can give a more direct way, not sure if inlining happens, but it sure is faster. > One approach I'm looking at is to pre select the method proxy and then > pass the proxy to a checking mechanism in the runtime system which > check to see if the proxy is still the best match and if so makes the > call via it. The reasoning behind this is that the checking process is > actually simpler than the selection process and the JIT may be able to > do lost more inlining. I'm still working on this. that isn't s much different from what we do for call sites, only that we don't do this in the core, but in the call site object. >> This design is very much oriented at invokedynamic, but we came up with >> this before invokednymic. Of course MethodHandles, such as described by >> John Rose will come in very handy here. Most of what can be done today >> with monkey patching and categories fits well in his new way. I plan >> also to restrict a MetaClass to be no longer replaceable, but mutating >> it is allowed. The downside of this is, that if you want for example >> write code that reacts to each method call, that you have to put that in >> a MetaMethod. But much of what is done today will work without change I >> think. > > You know that I think that making the Class MataClass mapping > immutable is a *very* good idea. However if you really are going to > propose this you need to raise it on the Groovy lists now. It's a huge > breaking change and, whilst it will get my enthusiastic support, is > going to cause a lot of problems for existing code. Before I go to the lists I need to see if how the current way can be emulated. But yes, it is a huge breaking change, that's why we schedule this for 2.0 bye blackdrag -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ http://www.g2one.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 -~----------~----~----~----~------~----~------~--~---
