Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > New JVM instruction invokedynamic

Thread Tools

New JVM instruction invokedynamic

Alessio Stalla
Posts: n/a
On Nov 15, 7:45*am, Ken Wesson <(E-Mail Removed)> 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:
> >>> <
> >> 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: 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,, and relinking it
when foo is redefined, instead of generating y(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...
Reply With Quote

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
MS JVM and Sun JVM problem Young-Jin Lee Java 3 01-21-2004 04:25 AM
Different behavior for newStringUTF() for Sun JVM and IBM Jvm Lasse Java 1 01-05-2004 07:49 PM
vhdl for implementing pre-fetch and an instruction cache Eqbal Z VHDL 3 11-16-2003 06:07 AM
Private Instruction Sharon Microsoft Certification 1 09-25-2003 08:39 PM
Re: Handling both MS JVM and Sun JVM Kevin Hooke Java 2 09-02-2003 05:31 AM