Any virtual machine produced by this project will be standards-conforming, in that it will not change the meaning or behavior of existing Java classes and classfile formats. They may define variations or extensions of the class format, or new kinds of objects, whose meaning and behavior are beyond the scope of current Java and JVM specifications.
However, these extended codes and data structures will interoperate as much as possible with Java objects.
In addition, as a way of delimiting separate prototyping efforts, each non-standard JVM feature must be controlled by a command line option of the form -XX:+Foo and disabled by default.
Summary and Table of Contents
|sub-project||-XX: flag||reference||bug ID||priority||status|
|Dynamic invocation||InvokeDynamic||jrose-blog||6655646||high (JSR 292)||spec EDR, implem 80%|
|Lightweight method objects||MethodHandleSupport||jrose-blog||6655638||high (JSR 292)||spec EDR, implem 80%|
|Lightweight bytecode loading||AnonymousClasses||jrose-blog||6653858||med||integrated in JDK 7|
|Interface injection||InterfaceInjection||jrose-blog||6804588||med (JSR 292)||proto begun|
|Continuations and stack introspection||StackContinuations||jrose-blog||6655643||med-low||proto 80%|
|Tail calls and tail recursion||TailCalls||jrose-blog||6804517||med||proto 80%|
|Tuples and value-oriented types||TupleSignatures||jrose-blog||6804523||med||no owner yet|
|Immediate wrapper types||ImmediateWrappers||jrose-blog||6674617||med||no owner yet|
|Runtime support for closures||(no JVM changes?)|
|Runtime support for multimethods||(no JVM changes)|
|Faster interface invocation||(performance only)||(multiple)|
|Faster reflection||(performance only)||(multiple)||ongoing|
|Symbolic freedom (non-Java names)||(no JVM changes)||jrose-blog||high||proto|
This key feature is tracked by bug 6655646.method handle is a lightweight reference to a method. A caller may invoke the method through the method handle without knowing the method’s name, enclosing class, or exact signature, yet the call runs at nearly the speed of a statically linked Java call. Method handles are required to glue together dynamic call sites, and are also useful in other settings.
There was a recent conversation in the Google jvm-languages group touching on these issues.
This feature is tracked by bug 6655638.http://blogs.oracle.com/jrose/entry/anonymous_classes_in_the_vm. They can provide a basis for experimenting with autonomous methods.
This feature is tracked by bug 6653858.
Adjoining a new method to an old class is also not difficult, especially if the method is allowed to be static (explicit receiver argument) and access only public features of the target class. This is a natural and powerful tactic for languages (like Scala and Fortress) which feature traits and open-ended type relationships (such as contravariance in function types).
A mechanism to change an object’s class is a related, perhaps harder problem, which needs further investigation. A very restrictive version of class changing called “class splitting” might work well. It would allow an object’s class to be updated to a slightly edited (perhaps interface-injected) copy of its original class.http://lambda-the-ultimate.org/node/1002 for an existing approach to this based on massive bytecode rewriting. The JVM can supply stack introspection primitives (copyStack, resumeStack) to get similar effects on standard (non-rewritten) bytecodes.
This feature is tracked by bug 6655643.http://blogs.oracle.com/jrose/entry/tail_calls_in_the_vm.
Recent work in the Python community has shown that tail calls can be used to build high-performance dynamic language implementations, based on lazy typestate elaboration. (See http://blogs.oracle.com/jrose/entry/a_day_with_pypy.) This should be followed up in the JVM.http://blogs.oracle.com/jrose/entry/tuples_in_the_vm. Integer.valueOf and similar methods. The frequent interconversion between boxes and primitives is also a matter of ongoing compiler optimization, including escape analysis. It would be possible to simplify both interpreted and optimized execution of these conversions by adding a Lisp-like “fixnum” object format into the JVM. On 64-bit systems the pointer format could easily pack both a (restricted) klass pointer and a 32-bit payload within the pointer format itself; on 32-bit systems more classic “low-tag” techniques would work better. This is an experiment work carrying out. http://groups.google.com/group/jvm-languages/web/implementation-of-multimethods-in-jvm-languages
The Dynamic Languages MOP Library project should be integrated with the new VM features.6580709. java.lang.reflect provides the current standard for invoking methods without static linking. Method handles are likely to provide a more efficient way to implement this important API. A rework of the reflection package may be warranted, see bug 6567922. has been prototyped. It may need extension to support structured names (such as package prefixes or intentional names).