Understanding invokedynamic
As you may know, John Rose (photo included, did you know he's a Scheme refugee?) announced a while ago the International InvokeDynamic Day (August the 28th, 2008).
This announcement is very important for people building interpreted languages on top of the JVM, such as Groovy, JRuby and friends.
If you ever wondered what invokedynamic is good for then you may be interested in reading this great presentation by Gilad Bracha.
(A great presentation: it's a long time since I last read 35 slides in less than 5 minutes!)
A small summary
A quick-and-dirty summary: invoke dynamic is about calling (invoking) methods of objects. And the exact type of those objects is unknown statically (at compile time) but is only known dymanically (at runtime).
This may look simple, but if you think about method overloading you're in trouble: if you have a "Foo.class" and a "Bar.class" with methods "print()", and you invoke "print()" on an object of unknown type, then what do you do? Do you invoke "print()" in "Foo.class" or do you invoke "print()" in "Bar.class"? What about if the object is not of type "Foo" nor "Bar"?
That's where invokedynamic enters the game, its a JVM instruction that allows you to decide which method to call, and then to call it. At runtime.
And, more importantly, it allows you to program that in Java (through the java.dyn.* package)
You can see an example of that Java code in John's Rose attachment in the announcement
Now, that's fantastic, isn't it?
Benefits for SISC?
I don't know what the benefits for SISC (my preferred Scheme interpreter) are. I think that SISC, as Jatha (a Lisp interpreter) is built on top of a virtual machine that runs in turn on top of the JVM.
Jatha is built on top of a SECD machine for instance.
And as a consequence I don't think invokedynamic is a real benefit for those implementations.
But, well, I may be wrong. And if so I'd appreciate a comment.
Happy invoke-dynamic, Antonio
blog comments powered by Disqus