Re: New JVM instruction invokedynamic
On Nov 15, 7:45 am, Ken Wesson <kwes...@gmail.com> wrote:
On Sun, 14 Nov 2010 14:07:12 +0000, Tom Anderson wrote:
On Sun, 14 Nov 2010, Ken Wesson wrote:
On Sat, 13 Nov 2010 16:07:49 +0100, M.O.B. i L. wrote:
I read this article:
<http://java.sun.com/developer/technicalArticles/DynTypeLang/
index.html>.
It's about the new JVM instruction invokedynamic that should make
dynamic languages faster.
Remind me: what does invokedynamic do differently from invokevirtual?
Everything.
It's not just a slightly looser version of invokevirtual which lets you
be a bit more vague about types in the bytecode. It involves a
completely new, and frankly batshit insane, calling process, which
involves finding and using things called MethodHandles, which are
objects, but which can get involved with the call process.
Bear in mind that dynamic languages (here i will use a dynamic version
of java i have just made up) don't just need to be able to do:
var foo = 23;
foo.toString(); // foo has no static type here
They need to be able to do:
var foo = 23;
foo.toQuotedString = do String() {return "'" + this.toString() + "'"'=
};
// made-up lambda syntax foo.toQuotedString(); // that method didn't
even exist a minute ago
Supporting that inside the JVM requires some serious voodoo.
invokedynamic is it.
Funny. I don't think clojure uses invokedynamic if you do something like
(def my-thingie {:value 23})
invokedynamic (indy for brevity) is not primarily directed at dynamic
languages in the vein of Clojure: its main target are languages like
Python, Ruby or JavaScript - dynamic, single-inheritance OO languages.
Indy allows such languages to integrate their method linking process
with the JVM, with the potential of making it more efficient,
essentially avoiding an extra layer of indirection: foo.bar(args) can
be compiled to <invokedynamic foo bar args> instead of
foo.findMethod("bar", args).apply(args). Clojure and Lisps in general
are not object-based but function-based instead (though they are
object-oriented, in their own way), and as such indy has much less
impact for them. It may still be useful to handle function
redefinition - linking (foo args) to, say,
com.my.lisp.CompiledFunction_foo_1234.apply(args), and relinking it
when foo is redefined, instead of generating
com.my.lisp.Runtime.getFunction(theSymbolFoo).apply(args). Whether
that is really beneficial or not is an open question. I am working on
integrating invokedynamic in ABCL (Armed Bear Common Lisp), but I'm
having trouble - not from indy per se but from the necessity of
integrating the "new" Java SE 6+ code verifier, which is not supported
by our compiler and is required to emit Java 7 bytecode. And it's a
pain to code...