Thanks for the detailed explanations guys. I have been playing with invokedynamic for a few months, and I can only second the remarks on the API documentation. They are not bad per-se, but broader documentation is lacking on the topic. What really helped me getting started was the following article from John Rose although its is not up-to-date anymore: http://dl.acm.org/citation.cfm?doid=1711506.1711508
Cheers On Tue, Nov 29, 2011 at 8:36 PM, Charles Oliver Nutter <[email protected]> wrote: > On Tue, Nov 29, 2011 at 6:39 AM, Jochen Theodorou <[email protected]> wrote: >> Am 28.11.2011 17:38, schrieb Julien Ponge: >> >>> Is it very different from the call sites in JRuby? They have a solid >> >>> invokedynamic implementation to look at already. Might inspire you in >>> a few places :-) >> >> Is it different? afaik JRuby does not care about Class.forName for example. >> Also I think JRuby doesn't have to handle method calls with a null receiver >> and other things. I think many things are common, but only with JRuby, with >> almost any invokedynamic using implementation. But you get into details very >> fast and then it is not so equal anymore. For the performance very important >> is also for example the guards you use. that is very much internal and thus >> very different for JRuby and Groovy. > > I tend to agree with Jochen here :) > > Groovy has a much more difficult set of problems to solve: > > * Dispatch is often (always?) dependent on the incoming types of the > arguments, since Groovy supports overloading methods based on type and > arity. Ruby does not support overloading, so we only ever need to look > up methods by name, and ensure incoming arg counts fit the target > method. JRuby does have to do full multimethod dispatch when calling > from Ruby to Java, but I've only wired that with invokedynamic in > single-arity cases so far. > > * I believe invalidation is more complicated since there's categories > (thread-downstream metaclass patching) and many types of metaclass, > including user-implemented (Ruby has basically one type, not > overridable). In JRuby, call site invalidation must do only two > things: confirm the incoming receiver is of an appropriate type, and > confirm it hasn't changed since last time. > > There will be similarities, but Groovy has harder problems to solve. I > would recommend just using invokedynamic a bit at a time, for dispatch > paths that are simple and don't require multimethod selection. That's > the approach I've taken with JRuby...simple things first. > > - 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. > > -- Julien Ponge http://julien.ponge.info/ -- 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.
