Sub-Projects and Investigations
This project is hosts a number of independent sub-projects. Some are under active development towards immediate standardization and delivery, while others lean more toward the middle future. In several cases, the projects are waiting for JVM developers who are willing and able to pursue them.
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|
A language compiler can compile a non-Java call site with a language-specific handler which determines call site linkage at runtime. Linkage can be sensitive to dynamic argument types, and can be updated or revoked over time.
This key feature is tracked by bug 6655646.
A 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.
Anonymous classes are a start; see 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.
It is a common occurrence in dynamic languages for pre-existing objects or classes to be given new supertypes. On the JVM, this would appear as a class which acquired a new interface, and the necessary method implementations. In Hotspot, an interface works like a tiny vtable which is placed inside the class. When an interface method is invoked, first the vtable is located, and then a more or less normal virtual call ensues. Adding a new vtable to an old class does not seem like a difficult problem.
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.
Continuations are a powerful way to gaining control over a thread's future execution. They are a standard feature of a few dynamic languages (notably Scheme) and have more recently been used to implement mobile or restartable computation sessions in some application frameworks. See: 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.
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.
Dynamic languages frequently interconvert (on the JVM) between primitive values (often ints) and their corresponding wrapper objects. This has been made easy with autoboxing in the Java language, and 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.
It is clear there is some relationship between the JVM’s notion of lightweight method handles and various proposals for extending the Java langauge with closures. The details need to be worked out.
Again, it is clear that JVM functionality for dynamic calls must remain fairly low-level, and that large amounts of library is needed to match the JVM capabilities to the requirements of high-level dynamic languages. An example of such ongoing work (independent of this project) is 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.
JVM users would generically benefit, and dynamic languages would specifically benefit, from further performance work on interface calls (and extensions described here). The performance work should cover profile-driven work (such as PICs or loop customization) and old-fashioned vtable tuning, for megamorphic calls. For the latter, see bug 6580709.
The package 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.
Non-Java languages have non-Java conventions for identifier formation. In the extreme case (Lisp) any string can serve as a name. Taking that most general case as a design motivation, a canonical “mangling” for arbitary name spelling is desirable, and has been prototyped. It may need extension to support structured names (such as package prefixes or intentional names).
This work mostly independent of the JVM, but may interact with some APIs which surface JVM symbols to error reports and other human-readable messages.