The JVM as Universal Parallel Glue?

The two days of the SiCS Multicore Days is now over, and it was a really fun event this year too. I will be writing a few things inspired by the event, and here is the first.

Kunle Olukotun‘s presentation on the work of the Stanford Pervasive Parallelism lab included a diagram where they showed a range of domain-specific languages (DSL) being compiled to a universal implementation language. That language is currently Scala, and in the end all applications end up being compiled into Scala byte codes, which are then optimized and dynamically reoptimized and executed on a particular hardware system based on the properties of that system. Fundamentally, the problem of creating and compiling a DSL, and combining program segments written in different DSLs, is solved by interposing a layer of indirection.

But this idea got me thinking about what the best such intermediary might be for large-scale general deployment.

And my conclusion is that the Java Virtual Machine might be the best candidate. Not the JVM as it is today, though. Here is my idea:

  • The Sun Java JDK and its optimized HotSpot VM is now open-source, thanks to the OpenJDK. This opens the door to new innovation based on solid technology.
  • The HotSpot is a pretty good VM, and therefore other languages are starting to use it as a potential backend. For example, Python can be compiled to the JVM, as can Ada, and I expect many other language environments to follow suit. The reason is that developing and optimizing a VM is hard work, and if there already is a good one in existence, targeting that is easier than doing you own.
  • I think that long-term, this might well replace C as the universal language that you target when you do special-purpose code generators from custom languages… which are really DSLs.
  • Thanks to this foreseen ubiquity of the OpenJDK JVM as a universal byte-code execution machine, it will provide a single point of leverage across a large range of applications in a multitude of programming languages.
  • As demonstrated by the work of the PPL and the approach taken by RapidMind, the idea of using an abstract byte code for software delivery makes very much sense in a heterogeneous and networked environment. It also provides a good infrastructure for analysis and optimization. It simply is very sensible.

However, the JVM as it stands today is not really suitable for this. It will need some extensions, which I am not the man to invent. With an open-source common JVM, such innovation will be easier to do. Thanks to Sun for opening up Java! For example:

  • Support for dynamic languages like Ruby and Python: not the same dependence on Java-type static typing and Java types. They work well for Java, but less so for other languages. It would be nice with lists for real as well, and not just as a library container.
  • Support for threads. Not OS threads, but the typical very light-weight threads used in environments like Erlang and OZ. Or even lighter, like the serial units of computations in the kernels of RapidMind and CUDA and similar GPGPU efforts.
  • Support for SIMD operations, to express data-level parallelism which is often pretty easy to find on a source-code level.
  • Support for data blocking, locality, tiling of some kind, to control data locality. Maybe this already exists in X10 (which I heard about at last year’s Multicore Day).
  • Support for communication using messages, and I assume that the best model for expressing the threads is through local data, share-nothing, message passing. With a special case for sharing large data blocks.
  • Some kind of data sharing mechanism that is more structured and understandable for a runtime system than pure locks & shared data.
  • And a system that takes such an advanced byte code and makes it run well on any particular machine, be it a Tilera Tile, an 8-core P4080, a 128000-core BlueGene, a GPGPU, or a plain middle-of-the-road UltraSparc T2.

So there is some work to be done. But I really think this idea has some merit… if only I had research funding and some good students. Or a crazy VC. 🙂

4 thoughts on “The JVM as Universal Parallel Glue?”

  1. You might already be familiar with it, but some people at Sun (John Rose is the driver) is working on MLVM, multi-language VM:

    http://openjdk.java.net/projects/mlvm/

    which is extending the JVM to better support dynamic languages. They are also discussing removal of some of the artificial limitations the JVM has which make it pretty tricky to work with when generating code – constant pool sizes, 64KB code sizes etc.

    I think Microsoft’s CIL bytecode is really better suited for this (e.g., IronPython), but Java probably still has too much of the “mindshare” for this to succeed.

    // Simon

  2. Thanks for the pointer!

    The reason I think this will get done in Java is that the JVM is now open. This makes it possible to modify the machine and port it to anywhere it is desired, which is not the case with a VM controlled by Microsoft.

    The Microsoft design generally seems better on the technical side, since it was conceived with multiple languages in mind and with the hindsight of having seen the JVM in action.

    Nice to hear from a JVM-as-target-for-non-Java-code expert on this!

  3. These would be some welcome improvements for the JVM. And I do agree that a lot of people are already targeting high-level languages like Ruby and Python to run on the JVM.

    The one recommendation about lightweight-threads would be really great–as I think this is one of the best features of erlang–however, I wonder about trying to make the JVM support concurrency while there are so many libraries out there that are not designed for such a thing. That is one of my concerns with Scala–I am sure it will be resolved in due time.

  4. Good point on legacy libraries… and I think that is something you could solve in two ways.

    Either say that if you are using some legacy library that is not thread-safe, you won’t be particularly parallel.

    Or you could insert some mechanism, probably separated-memory encapsulation, to make it possible to still run multiple instances of such software on separate cores on a multicore (one of the main ideas in how to harness multicores currently put forward by Anant Agarwal of Tilera at the SiCS Multicore Days).

    Anyway, the most important is probably to support the development of future applications based on customized domain-specific languages (or code generators like Lex/Yacc) that can express their parallelism in a nice way for the Universal VM to run on a parallel machine.

Leave a Reply

Your email address will not be published. Required fields are marked *