On 25 Ago, 20:21, Nick Zbinden <nick...@gmail.com> wrote:
> @Aaron: Could you go into why this is the case? What does jruby do
> that it needs it so much and clojure does not.
>
> @Tal Liron: You seem to differ in your opinion with Aaron (pretty sure
> you would not be investing your time otherwise). What exactlly are you
> attempting to speed up and how does invokedynamic help?

I'm neither of them, nor I am a Clojure hacker, but still I think I
can contribute something to the discussion.

invokedynamic is basically a hook in the JVM's linking system; it
allows language implementers to resolve method calls respecting the
semantics of their language, but letting the JVM know about it so it
can optimize those method calls.
invokedynamic is not just that - it has advanced features like the
ability to invalidate call sites (thus forcing the JVM to redo the
linking) or to emit guarded calls, in order to specialize "fast
paths" (e.g. primitive arithmetic) while providing a slow fallback
path (e.g. generic arithmetic).

It mostly benefits dynamic object-oriented languages - Ruby, Python,
Smalltalk etc. - because all their method calls can get promoted to
"native" JVM method calls instead of being implemented in user code.
In dynamic functional languages like Lisp dialects, method resolution
is not a problem - there's a single method, apply (simplifying things
a bit). invokedynamic can help with *class* resolution instead: now in
Clojure or Common Lisp every function call which is not inlined must
pass through the symbol (or Var in Clojure) - e.g.
functionNameSymbol.getFunction().apply(...). This is hard to optimize
because the actual class implementing the function is not known to the
JVM. With indy that pattern can become simply: invokedynamic
"functionName" args - and the Lisp system can resolve the function
only once (at least until it is redefined). I.e. the JVM will
translate that instruction to: invoke
TheClassImplementingTheFunction.apply(theFunctionInstance, ...args).
This should make function calls more optimized.

Advanced uses of invokedynamic - while complex - can implement things
like runtime type-based optimizations as well; but I don't know if
that's worth the effort for Lisps.

And perhaps there are other or alternative uses of invokedynamic that
I haven't considered, please share your ideas!

Peace,
Alessio

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Reply via email to