John Rose (JSR 292 spec leader) recently push a great patch that enables support for method handles inside the VM. A java.dyn.MethodHandle is a safe object that stands for a function pointer but unlike a function pointer, calling a method handle with wrong arguments raise an exception. The aim of method handles (with invokedynamic) is to ease the support of dynamic languages by the Java VM. But method handles is also a good candidate to implement closures :)

Using method handle VM support to implement closure

Let's take an example, I want to iterate over a collection and call a method (here sayHello) on each element. Using BGGA syntax, it's something like that:

  public static void each(Collection<?> c, {Object => void} closure) {
      for(Object element:c) {
          closure.invoke(element);
      }
  }  
  public static void sayHello(Object message) {
      System.out.println("hello "+message);
  }
  public static void main(String[] args) {
      {Object => void} closure=#sayHello;
      List list=Arrays.asList("BGGA", "closure");
      each(list, closure);
  }

And now using a MethodHandle:

  public static void each(Collection<?> c, MethodHandle mh) {
      for(Object element:c) {
          mh.invoke(element);
      }
  }
  public static void main(String[] args) {
      MethodType methodType=MethodType.make(void.class, Object.class);
      MethodHandle mh=MethodHandles.findStatic(MethodHandleTest.class, "sayHello", methodType); 
      
      List list=Arrays.asList("davinci", "closure");
      each(list, mh);
  }

To create a method handle, I first create its method type, here void(Object) then I perform a lookup using findStatic to find a static method named "sayHello" that takes an Object and returns void. And then I can call each with a list of String and my method handle (linked to sayHello).

Compile and ...

And it doesn't compile :(
In each, I call invoke() on a MethodHandle and this method doesn't exist at compile time. Remember how a method handle works, you always can call invoke with the arguments you want and the VM will raise an exception if arguments doesn't match parameter types. So, the VM understands the call, but the compiler is not already modified to allow to call invoke on a MethodHandle with any arguments.
Two solutions here:

1. Wait a prototype of the JSR on small language changes because the ability to invoke a MethodHandle is one of the proposed changes.
2. Generate the bytecode corresponding to that call by hand or better using ASM.

  class Magic {
    public static void invoke(MethodHandle mh, Object o) {
      // ASM will provide the magic :)
      // aload_0
      // aload_1
      // invokevirtual "invoke" "java/dyn/MethodHandle" "(Ljava/lang/Object;)V"
      // return
    }
  }

  public static void each(Collection<?> c, MethodHandle mh) {
      for(Object element:c) {
          Magic.invoke(mh, element);
      }
  }

And how to run it ?

Simple, take the hotspot source, the jdk source, take the mlvm patch queue, apply the patches named "meth" (no it's not for methadone), recompile the VM, recompile the JDK.
If you're lazy, and you use linux just take the binary of beta 42, and download this zip file
It contains two zips and a jar.

• vms.zip contains two pre-compiled VMs: davinci-client and davinci-server that must be unziped in jdk1.7.0/jre/lib/i386/.
• method-handles.jar contains additional classes like java.dyn.MethodHandle, etc.
• src.zip contains all the sources: the example above, the ASM code and the additional classes all under GPL + classpath exception.

  java -davinci-client -Xbootclasspath/p:method-handles.jar -XX:+MethodHandles fr.umlv.davinci.test.MethodHandleTest

Some open questions: Are method handles more efficient than reflection ? I think the answer is Yes but I let you that as an exercice. BGGA spec allows co/contravariance how to do that with method handles ? Hum, good question for a future blog entry.

Happy new year,
Rémi