JSR-292 and the Multi-Language VM

Posted by Geoffrey Wiseman on Oct 24, 2007

Sections

Development

Topics

Dynamic Languages ,

Java

Tags

Languages ,

JVM

The JSR-292 effort formed in early 2007 to improve support for dynamic languages on the Java Virtual Machine (JVM). Thus far, the effort has focused on an invokedynamic instruction for the JVM, but has recently included movement towards the creation of a multi-language virtual machine project. John Rose summarizes the results of a recent meeting:

• We are making significant changes to the JVM instruction architecture.
• The occasion for this is a crop of new dynamic languages. There are business reasons for the JVM to support these languages.
• EG consensus: We want public review early. This means producing an EDR (early draft review required by JCP).
• To make the current Proof of Concept design public, we need to pass the "red face test". That is, the design shows a direction that we as an EG think is worth explaining and improving. Since this is not a voting milestone, the EDR spec. can be incomplete and have unresolved issues.
• The original JSR 292 language includes not only invokedynamic but also some sort of class modification or extension. Based on recent experience, what's needed beyond invokedynamic is probably some sort of lightweight behavioral extension (method handles, autonomous methods, etc.). Further discussion is required.
• An OpenJDK open source sub-project is going to help create the RI (reference implementation required by JCP) for JSR 292.
• This project (the MLVM) is likely to include other changes, and it is up to our EG which changes we think are ready to standardize and which to push off to MR (maint. rel.) or another JSR.

To that end, John Rose proposed a Multi-Language VM Project on the OpenJDK list:

This project will be open for prototyping JVM features aimed at efficiently supporting languages other than Java.

The emphasis will be on completing the existing bytecode and execution architecture with general purpose extensions, as opposed to a new feature for just one language, or adjoining an unrelated new execution model.

The emphasis will also be on work which removes "pain points" already observed by implementors of successful or influential languages, as opposed to more speculative work on unproven features or niche languages.

The reaction has been mostly positive: "You have me hooked.", "Nice to see Sun continuing to grok the whole Java as a platform meme". It has also been constructive, from Neal Gafter's arithmetic peeve, Attila's meta-object protocols and Remi's reified generics.

At the same time, people recognize the dangers inherent in a challenge of this size.
Attila raises the spectre of Parrot:

Of course, there's always the danger of losing focus if the goal is
too broad; see history of Parrot for terrifying examples.

John Rose responds to that concern with:

Yes. That initial list of ideas, if fully explored, would cost
decades of work. (And that's just my own pick of favorites.) So there is (as always) a need to choose the most profitable projects first.

For more information, join the JSR-292 Observers list, the JVM Languages group, get adjusted to Mercurial and stay tuned to InfoQ's Java community.

• Older >