On 11/29/2011 08:36 PM, Charles Oliver Nutter 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.
Dispatch is not always dependent on the incoming type
because a lot of methods are not overloaded, in that case
a simple inlining cache will work.
There is a specific example in the cookbook about
how to implement the multi-dispatch, the example
is not finished (it only works if there is less that 32 overloads
but it can be adapted straightforwardly)
see https://code.google.com/p/jsr292-cookbook/
* 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.
I think the only viable option (on the long run) is to re-architect
the groovy MOP to be more Ruby-like.
- Charlie
Rémi
--
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.
