One of the most discussed features of the upcoming JDK 7 is a new JVM instruction designed specifically to support dynamic languages on the Java Virtual Machine. A version of the JVM with invokedynamic is already available from the JDK 7's community download site. Ed Ort's recent Sun Developer Network article, Support for Dynamically Typed Languages in the Java Virtual Machine, explains the ins and outs of invokedynamic, and discusses why previous alternative techniques for dynamic language support were not satisfactory:

With the addition of support for JSR 292 in JDK 7, dynamically typed languages should run faster in the JVM than they do today. A key part of this support is the addition of a new Java bytecode, invokedynamic, for method invocation, and an accompanying linkage mechanism that involves a new construct called a method handle. These features enable implementers of compilers for dynamically typed languages, that is, the people who develop compilers for languages such as JRuby and Jython, to generate bytecode that runs extremely fast in the JVM.

Ort notes that the biggest benefit of these JVM additions is improved performance for dynamic languages:

These features should boost the performance of code generated by dynamically typed language compilers that already run in the JVM. For example, the JRuby compiler generates bytecode that performs well in the JVM, but the JRuby bytecode will run even faster when the JRuby compiler is modified to use the invokedynamic bytecode and method handles.

Ort also places the work of JSR 292, "Supporting Dynamically Typed Languages on the Java Platform," in the context of earlier JSRs making it easier to run dynamic languages on the JVM:

JSR 223 ... specified a framework for hosting scripting engines in Java applications. A scripting engine is a program that compiles or interprets scripting code and then executes it. This specification and its implementation made it much easier to create applications that include both Java code and scripting code...

These scripting engines have faced a troublesome obstacle. When developers write engines for dynamically typed languages that run in the JVM, they have to satisfy the requirements of the Java bytecode that the JVM executes. Until now, that bytecode has been designed exclusively for statically typed languages...

What this means for a method invocation is that the compiler, and the bytecode it generates, needs to know the type of the value returned by the method as well as the types of any receiver or parameters specified in the call.

The rest of Ort's article goes into the details of why invokedynamic was required, and how it helps dynamic language implementers:

A lot of the bytecode execution in the JVM involves operations on values in an operand stack... the invokevirtual bytecode instruction is different... in that it invokes a method rather than manipulating the operand stack.

This information provides a signature for the method invocation. In response to the invokevirtual bytecode instruction, the JVM looks for a method with the supplied signature... If the method isn't in that class, the JVM searches up the chain of the class's superclasses...

Dynamically typed languages don't provide type information until runtime, [and] implementers must try various approaches to meet the bytecode requirements for method invocation...

What do you think of the JDK 7 JVM's support for dynamic languages?