On 11/29/2011 11:17 PM, Jochen Theodorou wrote:
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.
The VM still profile getMetaClass() so if you insert the call at
callsite instead of relying
on a method that itself call getMetaClass() you should have a narrow
profile that may
enable inlining.
This is something that currently doesn't work well with invokedynamic,
we need a way to ask the VM to use a different profile for a method
handle used
at different callsite.
The only way to get that currently is to generate code at runtime, which
is far from ideal.
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
[...]
bye Jochen
cheers,
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 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.
