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