happy new year!

John Rose John.Rose at Sun.COM
Tue Jan 20 00:48:30 PST 2009


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




More information about the mlvm-dev mailing list