Longjumps, Tailcalls, Tuples for the JVM

Posted by Geoffrey Wiseman on Sep 19, 2007

Sections

Development

Topics

Java ,

Dynamic Languages

Tags

JVM ,

Functional Programming

This summer, John Rose made a series of posts that Charles Nutter described as "some exciting articles about the future of the JVM and a number of changes potentially for the next Java version." Although John does occasionally touch on the impact to the Java language, the emphasis here is clearly on the VM, and many of these could be seen as important for supporting other languages on the JVM, including both functional and dynamic languages.

In the first of these posts, John Rose described longjumps, or non-local exits that may be necessary for some kinds of closures within the Java language. By using exception-handling mechanics with pre-allocated (e.g. cloned) stack traces, it's possible to get a non-local exit without paying the heavy price of exceptions for flow control. Done well, this can be less than three times the cost of a local exit/return and can be optimized to a machine-level goto instruction. This is particularly performant with a build of Java 7 that optimizes the cost of Object.clone().

Next, John tackles tail calls in the JVM: the ability to compress tail recursion in an explicit, guaranteed fashion ('hard tail calls') or as a compiler optimization ('soft tail calls'). This post evoked a lively discussion in the comments about approaches and uses, but tail calls would likely be of help to functional languages — or languages with some functional-language features — on the JVM, as well as dynamic languages that would benefit from invokedynamic (JSR-292):

It would apply to invokedynamic along with the others. Having hard tailcall would give you more options for implementing dynamic calls: You could branch to a dispatch routine, which would then tailcall the normal routine. (In fact, that's how java.lang.reflect.Method.invoke could work today, at least if return values are not to be boxed.) Since Scheme is a dynamic language, tailcalls are loosely related to JSR 292.

Finally, he looks at Tuples, raising a proposal that dates from 2004 and which describes both 'pure' tuple types (plain tuples) value classes with tuple semantics, which do not need to retain identity (tagged tuples). This can also encompass support for methods with multiple return values. Again, the emphasis on the JVM rather than the Java language is clear here:

It is likely that the tuple-enhanced language will provide a canonical translation between groups of typed values and references to heap objects carrying those values. For example, each value class is likely to support a constructor whose argument signature is the tagged tuple for that class. A tuple is likely to be representable on the heap as a fixed-length Object array or as a generic immutable utility class, with primitive component values in wrapper classes (as in varargs).

And again, in the lively comment thread:

Actually integrating value-like types into Java raises difficult design issues, as you point out clearly. My purpose for this post is to indicate that adding tuples to the JVM is fairly simple, and does not require solution of the language design problems.

Do these proposals strike a chord with you? Are you more interested in seeing the JVM increase support for different languages, or the evolution of the Java language, or are these non-conflicting goals? We'll try and keep you informed on all these topics at InfoQ.

1. Back to top

   Yes, please!

   by Thom Nichols

   Java is not necessarily the best tool for every job, but the real value is in the JVM and all of the libraries and frameworks built for it.
   
   To get the most out of the Java platform (and the JVM) it seems apparent that they should do their best to support other (read: dynamic) languages. .NET already has a head start with the DLR.

   Reply

2. Back to top

   They are better than non-conflicting goals

   by Ricky Clarkson

   Java's improvements will drive the JVM forward, and the JVM's improvements will make it easier to improve Java. Adding guaranteed tail calls and closures in the same release of Java would be a great step.

   Reply

3. Back to top

   Re: Yes, please!

   by Michael Neale

   Absolutely. Its good to see people looking at enhancements to the JVM that aren't driven with a short term view of what just the Java language spec has to do (which is much smaller then what the JVM can do).

   Reply

4. Back to top

   Advance the VM

   by Michael Krumlauf

   Of course. To constrain the VM merely to conform to the constraints of the Java language would be short-sighted. There don't seem to be any backwards-compatibility issues, so there doesn't seem to be any reason not to proceed with improvements to the VM.

   Reply

• Older >