Am 29.11.2011 20:36, schrieb Charles Oliver Nutter:
[...]
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.
very often, yes. We don't need to do it for primitives for examples. But
that requires static type information. In theory you can force method
selection a bit if the static and the runtime types are equal, which
would be the case for final classes. But that is for somewhat later.
[...]
* 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.
categories are with my current plans actually less a problem. The
problem is more that you can create a new meta class and not use it. I
could have an easy life if I could recognize the setting of a meta
class. But this may happen in Java code, with a class that is not
written in Groovy, just implements GroovyObject and so on. This is a
problem that I intend to solve with MOP2, but that is not for the
current or the next version of Groovy. Currently I more or less would
have to recognize that the meta class for a receiver is still what I
expect. For Java classes I have control over them getting a new meta
class set, so I can there go with a general approach... strangely
meaning that it will be slower for groovy classes... where I will have
to execute the getter first to get the meta class.
Funny fact is our compares. From old times we have a method being called
directly from the bytecode here. We made this back then for performance
reasons. And back then it made sense. But with near java speed method
calls, this makes no sense anymore, because this method cannot be
inlined. It is horribly big and a JIT nightmare. Most probably I will
for invokedynamic split the method and let invokedynamic operate only on
the sub parts really needed. Without that lots of performance would be lost.
also for math operations I will have to have a big look
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.
well, my first steps have been to make forced method selection work
(requires a value being unwrapped), GString conversion and null
receiver. So more than only most simple scripts run already. But it is
without guards, without static method calls, without calls to methods
with reduced visibility. After those are done I will compile and test
run all our test cases to see if invokedynamic can really do a full
replacement or if there are still some bugs.
bye Jochen
--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to jvm-languages@googlegroups.com.
To unsubscribe from this group, send email to
jvm-languages+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
