Longjumps, Tailcalls, Tuples for the JVM

| by Geoffrey Wiseman Follow 0 Followers on Sep 19, 2007. Estimated reading time: 2 minutes |

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.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

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.

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.

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).

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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you