JVMLS 2016: A Recap of Java Virtual Machine Language Summit

Last week was the Java Virtual Machine Language Summit, where language designers and JVM engineers come together every year to present the newest developments and discuss the future of the virtual machine. For us Java developers this might seem one step removed, after all the JVM is just the machinery executing our code. And the event itself is thoroughly overshadowed by the upcoming JavaOne.

But make no mistake, the JVM stepped out of Java’s shadow long ago and leads a life of its own. Just consider all the innovative languages that run on the JVM and triggered improvements in Java (cough, lambda expressions, cough). And don’t overlook how the JVM’s limitations and capabilities keep influencing the language’s evolution. It is impossible not only to gain a deeper understanding of Java when ignoring the JVM, but also to contemplate Java’s future without considering the JVM’s.

So to get a feeling for where Java is going it is essential to look at where the JVM is going. And the JVMLS lets us do just that! There were talks about a lot of interesting topics but I want to focus on three.

Project Jigsaw

Project Jigsaw is Java 9‘s flagship feature and will bring modularity to the language. It will allow developers to create modules and promises reliable configuration and strong encapsulation as well as improved scalability, security, and performance.

In Java 9 we will be able to create modules, where a module is just a JAR containing a new construct – a module descriptor. It describes a module by giving it a name, listing the other modules it requires, and the packages it exports. At runtime, modules can (mostly) only see modules they require (this is called Readability) and can only access types in other modules if they read that module and that module exports the package containing the type (called Accessibility).

This means that the compiler and JVM finally abandon the big ball of mud, into which they used to roll all our code and our dependencies. Instead we will get a real graph that closely mirrors our perception of how our software is structured. And both the compiler and the JVM will understand that graph! They will note when something is missing, when there are two versions of the same module, when two modules export the same packages, etc. And they will fail at compile or launch time instead of throwing errors at runtime or, worse, misbehaving subtly.

To get a deeper insight, see Alex Buckley’s talk “Poject Jigsaw – Under The Hood” or have a look at the Jigsaw resources on my blog, maybe start with this walkthrough to get your hands dirty. Other Jigsaw-related presentations are Claes Redestad’s “JLink-Time Optimization” and, especially interesting for those working with Nashorn, Michael Haupt’s “Nashorn Modularity”

Project Valhalla

Project Valhalla aims to introduce value types, which can be summarized as self-defined primitives.

Like primitives, value types incur neither memory overhead nor indirection. A self-defined point with two int fields x and y will be inlined wherever it is used. It will only require the memory needed for those two ints and an array of points will essentially be an array of x/y pairs. Like primitives, such points have no identity – while there can be two different Integer objects with value 5, there can’t be two different ints 5.

Like classes, value types can have methods and fields and implement interfaces. Thus the slogan: “Codes like a class, works like an int.” This will allow us to no longer weigh an abstraction we would prefer against the performance (we imagine) we need.

But the project quickly got sidetracked. As you know, generics do not work for primitives – there can’t be an ArrayList<int>. This is already painful with eight primitives (see the primitive specializations of Stream or libraries like Trove) but becomes unbearable when developers can define more. If value types would have to be boxed to interact with generics (like primitives are today), their use would be fairly limited and they would be a non-starter.

So we want to be able to use generics with value types – and primitives can come along for the ride. In the end we not only want to instantiate an ArrayList<int> or ArrayList<point>, we also want it to be backed by an int[] or point[], respectively. This is called specialization and opens a whole new can of worms.

To take a good look at those worms, watch Brian Goetz’ talk “Adventures in Parametric Polymorphism”. If you want to go deeper, watch last year’s talk – preferably first – and follow with Maurizio Cimadamore’s “Valhalla Reflection – One Mirror To Rule’em All” and maybe even Remi Forax’ “Valhalla Backport”

If we’re lucky some or even all of this will end up in Java 10.

Virtual Machine Futures

And then there is John Rose, the gray eminence sitting in the background and pulling the strings. With the all the hot topics taken he talked about the siren calls that lure the VM into its future:

• a uniform model over objects, values, arrays, methods, etc
• continued work on performance, for example with regards to memory efficiency by increasing density and sharing, and with continued optimizations of hot paths
• granular concurrency with fibers surpassing threads as the core abstraction
• becoming ever more useful, compatible, and interoperable – for languages running on top of it as well as for native ones, thus healing the rift between them
• stack reification, where the stack holds classes and methods as true objects, not just as strings, and where each frame’s full context (locals, monitors, etc) is visible and the stack can be edited by the running program

Honestly, much of what John Rose envisions is way over my head. But it’s great to listen to him anyway, if just to soak up his enthusiasm. You don’t have to take my word for it, just watch “VM Futures” and see for yourself!

Much in the spirit of Rose’s outlook is Project Panama, about which Mikel Vidstedt and Tobi Ajila talk in “Going Native”, and to which Ian Graves adds the “Vector API For Java”. Also aimed at healing the rift is Christian Wimmer’s presentation about the “One Compiler”.

Summary

The JVM is a powerful beast and a lot of intelligent people are working hard to make it more so while keeping the complexities under control. Are they doing a good job, what do you think?

And if all of that is too far removed from your daily work, be back in a month when we cover JavaOne 2016!

Frequently Asked Questions about JVM Language Summit 2016