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.

alt="Helicopter"

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

Dynamic invocation

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.

Lightweight method objects

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.

Lightweight bytecode loading

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.

Interface injection

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 and stack introspection

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.

Tail calls and tail recursion

See: 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.

Tuples and value-oriented types

See: http://blogs.oracle.com/jrose/entry/tuples_in_the_vm.

Immediate wrapper types

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.

Runtime support for closures

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.

Runtime support for multimethods

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.

Faster interface invocation

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.

Some recent work in the JVM has prepared the ground for this work, but more may be desirable. See bugs , 6525802, 6516101, 6461827, and 6428387.

Faster reflection

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.

Some recent work in the JVM has prepared the ground for this work, but more may be desirable. See bugs 6516018, 6525802, 6516101, 6461827, and 6428387.

Symbolic freedom (non-Java names)

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.