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 experimented with something like that. Basically selecting a method with one call to the runtime system and executing it by making a call to the object returned. My main motivation for trying this was to minimise the number of extra stack frames use for each call (i.e. to minimise the size of the stack trace printed when an exception is uncought). 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. 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. > > 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. John Wilson --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
