As you may have noticed, I just pushed a new patch set for method handles. This closes off a coding sprint (or hike or ramble?) that began in early December. The main visible results are a more mature javadoc API (draft--draft--draft!) and a bunch of unit tests. The unit tests, even though they are limited, provide the best "cookbook" so far for using method handles.
Under the hood, the code has been made more modular, and I have tried to move work from JVM C++ code to trusted Java code (the shape of the future). There is a complete set of non-blocking machine-level adapters. (A non-blocking adapter is one which does not need to run Java code and has no allocation points. Unboxing is non-blocking, while boxing can block and must therefore be done in a Java-based adapter.) Missing bits include Java-based adapters, optimizer support (i.e., code-generation of MH's which are compile-time constants) and integration of proposed Java language changes for invokedynamic and direct method handle invocation. The unit tests use a clunky "invoker" class which requires the arguments to be boxed and varargs- ed, which is what method handles and invokedynamic are supposed to help us avoid. As I see it, here's what needs to happen soon on the mlvm project. 1. finish the next draft of the invokedynamic spec. for the JSR 292 EG to consider (this is roughly coordinated with the implementation work) 2. get a code review cycle done so we can move more of the JSR 292 RI into the JDK 7 workspace 3. update indy.patch to follow meth.patch 4. figuring out how to integrate a modified javac (w/ JSR 292 support) into NetBeans, so we can write test case code with native syntax for method handles and invokedynamic 5. encourage the great work that people are doing or will do on tail call, continuations, interface injection, invokedynamic, etc. (Cheers, Arnold, Lukas, Tobias, Remi.) 6. assist Sun's test engineers as they begin building a real test suite 7. add JIT support, especially for inlining method handles at invokedynamic sites 8. work with brave language implementors (hi, Charlie, Brian) who want to try this stuff out sooner rather than later Best wishes for a Multi-Lingual New Year! -- John P.S. Re #4, if you know any netbeans hackers out there who want to help the JVM support new languages, you might let them know about these tiny language changes we will be proposing: http://hg.openjdk.java.net/mlvm/mlvm/langtools/file/tip/meth.txt http://hg.openjdk.java.net/mlvm/mlvm/langtools/file/tip/quid.txt _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
