the golden spike

Part 1: the road to Babel

In the Java cosmos we can reckon time in terms of JavaOne conferences. For programming languages on the JVM, the just-finished epoch has seen much progress, and the next epoch looks even better. Here is some of the progress that I am excited about, after bouncing around at JavaOne:

• Started just in the last year, the JVM Languages Google group has carried dozens of in-depth conversations between language implementors. (Thanks, Charlie!) It has been a great place to air new ideas and sort out complicated design questions.
• After about 20 months of hard work, JRuby (JVM implementation of Ruby) is reporting competitive performance with the original C-based Ruby, strengthening hopes that, (in Tim Bray’s words as posted by Frank Sommers), “If we arrange for JRuby to be compiled into Java bytecodes, it’ll be running on the JVM, which is one of the world’s most heavily-optimized pieces of software. So JRuby might end up having a general performance advantage.”
• In the JavaOne talks, the Jython and Groovy projects are reporting similar efforts to slim down their runtime overheads. They lag behind JRuby in this, but they are also making use of JRuby’s hard-won experience.
• This week, I enjoyed in-depth conversations with key developers of all three languages. I found they are enthusiastically determined to remove layers of overhead between their languages and the JVM they run on. With JRuby in the lead, they are stripping excess dispatching logic, and getting close to the point where the remaining obstacles to speed are a problem not with their system, but with the JVM. I think we all hope that, when the dust clears in a year or two, nearly Java-like performance will be a normal experience for optimized dynamic languages.
• Language developers are working towards common runtime support libraries on the JVM, to share coding effort, and (more importantly) to embody best practices for structuring the lower levels of the language runtime. In his CommunityOne talk “The Road to Babel”, Charlie Nutter eloquently raised this flag, and offered to contribute code from JRuby. And Attila Szegedi has been working steadily on metaobject infrastructure for JVM languages.
• At JavaOne I saw a various impressive demos of workstation-like Java stuff running on cell phones. It is clear that mobile device software is in a confused scrum including iPhone, JavaFX, Java ME, and Android, and also is, this year, in a race to the top. The goal of the race is still undiscovered, but doubtless will include a mix of scripting, dynamic languages, and virtual-machine based runtimes. I expect Java will be part of the winning mix.
• On the pavilion floor I ran into David Chase and Christine Flood of the Fortress Project. They are mostly done with language design and interpreter implementation, and are thinking about compilation to the JVM. Disregarding the desperately cool stuff about parallelism, modern types, DSLs, and mathematical notation, it seemed like any other fledgling interpreted language ready to mature into a compiled one. David, Christine, Bernd Mathiske and I had a great talk about compiling overloading, traits, continuations, and other tricky bits to the JVM, including possible JVMs of the near future. The JVM will be there to help Fortress lead the multicore revolution.

Interlude: Railroad history

In other news, today (May 10th) is National Train Day. On this day 139 years ago, a ceremonial golden spike was driven at Promontory Summit, Utah, joining the Central Pacific and Union Pacific railways into a single transcontinental line. The continent was very suddenly smaller, because people, goods, and mail could be moved more quickly from coast to coast, a task which was previously done with wagons, horses, and boats. In the years leading up to this watershed event, two railroads were built, with great difficulty and ingenuity, from each coast, to meet at Promontory Summit.

There is a Promontory Summit and a golden spike in our future also: I mean, in the future of us JVM and language geeks. I have been describing efforts of the wild and wooly dynamic language types to forge their way eastward, from the sunny shores of La-La Language Land across the forbidding peaks of metaobject-based optimizations.

Meanwhile, we JVM developers have been working our way west from the drab industrial zones of profile-directed optimization, loop transformation, code generation, cycle counting, and the SpecJBB benchmarks. We have always held the early Smalltalk and Lisp implementors in reverence; some of our technology even ran Smalltalk before it ran Java. How pleasant it would be to prove that the JVM has what it takes to run not only Java but also Smalltalk and its many hyperactive little brothers.

Language developers, working to bring their systems down to the virtual metal of the Java virtual machine, will find their last mile blocked by JVM features they cannot work around. But as they reach that point, they will find the JVM engineers have been working to make the JVM open to the passage of new codes. We JVM geeks are reshaping the virtual metal of the JVM to remove restrictions peculiar to Java, to make it accept the new shapes soon to be produced by the dynamic language compilers.

Part 2: making hard things as easy as the easy things

JVM optimization tricks (here are some of HotSpot’s) are of course occasioned by problems in Java programs. But the tricks are mostly the same (though updated) as those which streamline the machine code for Smalltalk and other dynamic languages.

For example, in my own work on HotSpot, I refactored parts of the system to unify the compilation of corresponding reflective and non-reflective operations, so that the same code generation paths handle both cases, for operations like object creation, type testing, and bulk copying. Reflective operations fold down to the same code as their regular counterparts, if the class parameters are non-constant, and the reflective overheads are still small when the classes are non-constant. This is sometimes useful for Java. More to the poitn, it is always useful for dynamic languages.

In the JVM, the crucial action is usually around call sites, and here the road is almost blocked to dynamic languages. The syntax of JVM call sites (in the bytecodes) favors Java and disfavors any call which does not follow the rules of Java’s static typing system. To get past this point, dynamic language implementors are forced to load their belongings into the overland wagon train, fitting all their objects into a limited set of implementation classes—language-specific wrappers—whose Java types express all the operations needed by the languages. Or, they choose the reflective water route, taking a slow boat through the general Core Reflection API offered by the JVM. (Some build their own speedboats, crafting their own somewhat faster reflection mechanisms, but none approach the speed of normal method calls, which are the JVM’s natural element.) At this point, some travellers may give up the journey toward native code, and go back home to tree-walking interpreters. (Yo, those are palm trees, dude.)

But the golden spike will be driven when the language developers have done all they can, and the JVM has removed its restrictions against calls outside the Java type system. More generally, the express trains from La La Land to industrial-strength machine code will start running when JVM languages are compiling to the virtual metal, and the virtual metal no longer has unnecessary restrictions inherited from the JVM’s single-language days.

Part 3: the JVM breaks out

This leads me to a second list of observations which I am happy to make this week, about the reshaping of the JVM in the last year.

• As Charlie Nutter reports, the current state of the JVM art is delivering great benefits to languages beyond Java. There is no better starting point than happy customers who will be even happier with a better product.
• The OpenJDK open-sourcing of the HotSpot JVM is finally, really open for business. I know we announced it last JavaOne, but now the public repository is the live, primary copy of the code. If a Sun engineer like me fixes a bug, you will see the fix within minutes of integration, in a public repository like the one my workgroup uses. Now anybody can contribute to the HotSpot JVM. Crucially, this means no more waiting for Sun (or IBM or BEA) business priorities to line up with your pet project: You can change JVM history by adding to the JVM. Vote with Code!
• Encouraged by co-workers, and by a sense that the time had come at last, I opened the Da Vinci Machine Project, an incubator for new language support in the JVM, including both crazy and sober ideas. (I will let you decide which is which.) It is built on, and part of, the OpenJDK project. I posted the first patch (for anonymous classes) in January, and saw people building it almost immediately. I especially liked the early adopter comment, “New toys!” Actually the JVM is full of great toys; we are now unlocking the toybox to kids on the non-Java playgrounds.
• Several non-Sun developers (thanks, Remi, Lukas, Arnold, Selvan) have already contributed code or design ideas to the project. One contributor is about to commit fully working runtime support for continuations.
• Charlie Nutter, pioneer that he is, has begun the experiment of integrating the anonymous classes facility into JRuby.
• The ever-bubbling blogosphere has blessed the project with buzz, much of it curious and friendly. There have also been three conference presentations, plus numerous favorable mentions at JavaOne. (No, I did not present at this JavaOne. Next year.)
• The JSR 292 Expert Group met at JavaOne, with face-to-face representation of three competing JVMs (HotSpot, J9, JRockit) and two languages (Groovy, Jython). The EG has been hashing out details the invokedynamic instruction, and has released (to the JCP) its first Early Draft Review.
• In the last year I have shared (in this blog) many long-held aspirations for the JVM, concerning tail calls, tuples, anonymous classes, exotic names, fixnums, method handles, continuations, interface injection, and dynamic invocation. None of these ideas is new, and my personal involvement with them goes way back to my pre-Java days (Common Lisp, and the cute little Scheme VM I left behind). These ideas are old and new again; their time is coming in the mainstream world of the JVM. In the next year or two, I hope to see each of them at least lightly incubated, if not cooked to perfection and served on a JSR.
• I think we are on the right track here, letting the JVM grow independently of the Java language. (The language, if it has room to grow, will catch up.) James Gosling expressed a similar sentiment at his February Java Users Group talk “The Feel of Java, Revisited”, when he said he sometimes felt more interested in the future of the JVM than that of the Java language. “I don’t really care about the Java language. All the magic is in the JVM specification.” (Yes, I think that is hyperbolic. No, he is not abandoning Java.) I love both Java and the JVM, and I am pushing on the JVM this year.

It has been a great year to be a JVM languages geek, and the coming year looks even better. With an incubator repository open, a draft standard in flight, and language implementors eager to collaborate, we are ready to cut some serious JVM code. Watch this space!

Posted by jrose [JVM] ( May 10, 2008 01:24 PM ) Permalink | Comments[1]